対象読者
- RemixがNext.jsなどとはどんなところが違うのか知りたいJavaScriptエンジニア
- WebブラウザとNode.jsという異なるランタイムをそれぞれキャッチアップするのが辛くなってきたエンジニア
前提環境
筆者の検証環境は以下の通りです。
- macOS Monterey 12.5.1
- Remix 1.7.1
Webフロントエンド技術の広がり
Webブラウザ上で動くアプリケーション周辺のエンジニアリング分野は、JavaScriptの進化とともにサーバーサイドの責務から分離され、「Webフロントエンド」という名前で呼ばれることが多くなりました。この分野は、Webブラウザをランタイムとしてリッチなアプリケーションを効率良く開発し、ユーザーに良い体験を与えることを主な目的としていると、筆者は認識しています。
ここで着目したいのが、このWebフロントエンド分野においては「Webブラウザでアプリケーションを動かす」だけではなく、「効率良く開発」することや「ユーザーに良い体験を与える」ことに大きな比重が置かれているということです。これらはWebブラウザ上で動くJavaScriptだけでは解決できない課題も含んでいるため、Webブラウザの外側の周辺技術が大きく発達することとなりました。
この周辺技術の広がりが本記事で扱う課題を理解するために無視できないものなので、少し長い前置きになりますが、解説させてください。
シングルページアプリケーション
Webフロントエンドという分野が成立するきっかけとなったWebアプリケーションの1形態として、シングルページアプリケーションと呼ばれるものがあります。
PHPのように、サーバーサイドでデータをすべて準備して、データを埋め込んだ状態で生成したHTMLをレスポンスとして返すアプローチとは異なり、シングルページアプリケーションでは最低限の記述のみがされたHTMLを受け取った後で、JavaScriptが自発的にAPIサーバーへ非同期通信を行い、Webブラウザ側で動的にUIを構築します。画面遷移も1つのHTMLの中身を動的に書き換える形で表現するため、「シングルページ」アプリケーションと呼ばれるようになりました（図1）。
ページをリロードすることなく、UIが次々とユーザーに反応を返せるため、ユーザー体験の良いアプリケーションを作りやすくなりました。
こういったアプリケーションの開発を後押ししたのが、JavaScriptをビルドする、各種の変換ツールです。Node.jsのパッケージマネージャであるNPMで配布されているBabelやwebpackなどのツールのおかげで、高級な言語で多様なライブラリを使用して作成したアプリケーションを、Webブラウザ上で動作する形へと変換できるようになりました。
シングルページアプリケーションの開発においては、手元のパソコン上でビルドのためにNode.jsランタイムのコマンドラインツールを実行する機会はあるものの、開発対象のアプリケーションとしては、Webブラウザ上で動くWeb APIへの十分な理解と、使用しているフレームワークについての知識があれば、問題なく開発が進められるものでした。
サーバーサイドJavaScriptによるユーザー体験の向上
シングルページアプリケーションがある程度普及した頃に、新たな課題が見つかりました。ユーザーの通信環境が、想定より少し良くなかったのです。
シングルページアプリケーションでは、大雑把に分けて、次の3段階の通信を経て画面の初期表示を実現します。
- HTMLファイルをダウンロードする
- HTMLに記載されているJavaScriptファイル、CSSファイルをダウンロードする
- JavaScriptが非同期通信を行い、通信結果を動的にUIへ反映する
このサーバーとの3往復の通信は順番に行われ、並列に実行できるものではありません。特に3番目の非同期通信は、アプリケーションの設計によっては複数のfetchを実施する必要があるため、3往復どころか5往復、10往復の通信を行った後にならないと、画面の表示ができないかもしれません。すべてのユーザーが爆速の通信環境を持っていれば、大した待ち時間にはならないかもしれませんが、残念ながら現実にはユーザーのモバイル回線はさほど速くはないので、ユーザーに大きな待ち時間を強いることになります（図2）。
これらを解決するためのアプローチのひとつとして、サーバーサイドレンダリング（Server Side Rendering、SSR）という手法が考案されました。サーバーサイドで初期表示用のデータを用意し、HTMLにデータを埋め込んだ状態で最初のレスポンスを返すというものです。これによって、初期表示時の通信は次のように変わります。
- Webサーバーがデータソースにアクセスして、データを取得する
- データを埋め込んだHTMLデータを生成する
- HTMLファイルをダウンロードする
- HTMLに記載されているJavaScriptファイル、CSSファイルをダウンロードする
- JavaScriptが実行され、UIを動的な更新の管理下に置く（見た目は変わらない）
SSRにもいくつか流派はありますが、理想的なのは上記のような形です。なんといっても、4番目の工程でCSSファイルのダウンロードまで終われば、HTMLにはデータが埋め込み済みなので、それ以上の通信を待たずに画面を表示できるのです（図3）。
こういったメリットから、通信回数を最小限に抑えられる手法として、SSRは重宝されるようになりました。
単純なシングルページアプリケーションと比べて少し面倒になった点として、静的なHTML/CSS/JavaScriptのファイルを配信するだけだったWebサーバーが、初期表示用のデータ読み込みと、HTMLの生成までを担うことになりました。開発を簡略化するために、Webブラウザ向けのUIフレームワーク（ReactやVue）でWebブラウザのために記述したUI描画の処理をサーバーサイドで動かすことでHTMLを生成するため、Node.jsによるWebサーバーがこの役割を担います。
Webブラウザでのユーザー体験を良くしたり、開発効率を上げたりするための手法を突き詰めた結果、Node.js製のWebサーバーで初期表示用のデータを用意する処理を書く必要が出てきました。これもまた、Webフロントエンド分野のひとつとみなされています。少し不思議なことではありますが、今日のWebフロントエンド分野には、サーバーサイドJavaScriptのAPIをよく理解し、記述する責務も含まれているのです。
