見出し画像

フロントエンドの用語に関するメモ

とあるオンラインセミナーの中でフロントエンドに関する基本的な知識を説明されている箇所がありました。説明されていたの代表的なフロントエンドである、SPA、SSR、JAMstackです。

SPAとSSRは聞いたことあったのですが、JAMstackはいまいち把握しておらず、ちょうど自分自身の知識として不足していたところでしたので、把握を含めてこちらに整理したものを書きます。

SPA

Single Page Applicationの略で、初回アクセス時にアプリの動作に必要なJavaScriptファイルやCSSなど、静的なアセットを端末にはじめにDownloadし、クライアント側で画面を構築する仕組みです。

単一の画面をJavaScript側の処理で表示を切り替えることで画面遷移を表現しています。画面の描画に必要なデータのやりとりは、RestAPIやGraphQLなどのAPIを利用しており、一度画面を表示すれば、以降の画面切り替えやデータのやりとりは高速に行われます。

初回のアクセス時にある程度まとまったアセットを一括で端末にDLする特性のため、初回の画面表示が遅くなってしまう傾向があり、画面のレンダリングが完了するまでに、未完成の状態(表示されないコンテンツ)が画面に表示されることがあります。それにより、SEOの観点で不利になる場合がある、と言われているようです。

SSR

Server Side Renderingの略で、上記SPAでの初回表示の課題を解決するために用意されたアーキテクチャで、APIサーバとクライアントの間にページを生成するためのレンダリングサーバを用意する仕組みです。

SPAでは画面を構築する作業はクライアントで行っていますが、SSRではレンダリングサーバに委譲しています。
クライントは構築済みのページを受け取るのみなので、画面の表示が高速化されるのと、未完成の状態が画面に表示されることが少なくなるため、SEOの観点でSPAより優位になります。
また、SPAと同様にクライアントから直接APIを呼ぶことも可能のため、
一部の処理をSSRにして、他をSPAと同様にクライアントで構築することもできます。

そうすると、すべてのアプリでSSRを導入すればいいのでは?と思ってしまいます。

SSRを導入するときの注意点としては以下の2つがあります。

1つめは、SSRのシステム構成はSPAと比較してレンダリングサーバというインフラのコンポーネントが一つ増えています。そのため、インフラの実装や運用コストが増えます。

2つめは、レンダリング処理をレンダリングサーバー側で行うのか、クライアントで行うかなどの実装の棲み分けが発生するため、アプリの実装コストも上がる可能性があります。

上記2つの注意点を考慮しつつ、SSRのメリットを得たいかどうかを検討するとよさそうです。

例として、SEOが必要でない小さな社内向けのシステムであれば、構成がシンプルなSPAを選択するほうがよかったりする場合があるようです。

JAMstack、SSG(Static Site Generator)

SPAやSSRのように従来のリクエストを受けてから動的なHTMLを構築するのではなく、アプリのビルド時にあらかじめすべてのページを作成しておき、配信する仕組みのものです。

例として、とあるECサイトで商品を検索し、表示された一覧から好きな商品を選択して商品の詳細画面を表示する処理があるとします。詳細画面遷移時にAPIをコールして毎回描画するのではなく、
あらかじめ商品点数がわかっている(100個など)のであれば、
ビルド時に詳細画面100ページ分作っておき、その100ページ分を配信サーバから配信するだけにしておく考え方がJAMstackです。

配信サーバから構築済みのページをそのまま返却するため、配信が高速で、
画面遷移の度にAPIコールが発生しないので、APIの負荷コストも低く抑えられます。

では、どうやって静的なページを作っておくのか?ということですが、ビルド時にページ生成に必要なデータをAPI経由、もしくはデータソースに直接問い合わせます。
商品詳細画面の例ですと、商品情報が格納されているDatabaseに各商品のデータを問い合わせる処理を行う処理を行います。
取得したデータをもとに静的なHTMLを作成し、配信サーバで配信する準備をするところまでをアプリのビルドで行います。この事前に静的なページを作成する仕組みがSSG(Static Site Generator)と呼ばれる考え方です。

構成の注意点は、ページのデータの更新が行われるのはビルド時のみになりますので、データソースのデータが更新されても、ビルドでページの再作成が行われない限り、サイトに表示されるページの内容は更新されません。
そのため、速報性の高い画面の場合はSPAやSSRのようにクライントからAPIをコールしてデータソースから最新のデータを取得する実装が必要になります。

もう1つの注意点として、生成するページの量に比例してビルドの時間が長くなります。商品点数が数十万、数百万の場合は現実的な時間でビルドが完了しない可能性がでてきます。

上記を踏まえてJAMStackが適切かどうかを判断していく必要があります。

さいごに
フロントエンドに関する用語について基本的な部分が理解できたので、サービスの開発をしていくときにイメージがしやすくなりそうです。

この記事が気に入ったらサポートをしてみませんか?