歴史
3層モデルのWebアプリケーション
Web-APP-DBのよくあるやつですね。ApacheにHTMLやCSSをおいて動的な部分はTomcatに任せるやつです。
Ajaxの登場
GoogleMapのやつですね。ブラウザを更新することなく非同期でサーバと通信を行いデータの取得や更新を行います。これによりUXを高めるのに大きく貢献した技術です。この後紹介するSPA(Single Page Application)の中核をなす技術です。
jQueryの登場
それまでJSでちょこっとアラート出すぐらいだったのがこいつの登場でガラッと変わります。一度ブラウザに返却したHTMLをユーザの操作に従って動的に変更する仕組みが整備されることになります。
HTML5の策定
HistoryAPIによってページの遷移をWebブラウザだけでなくJSでも管理できるようになりました。これによってコンテンツを画面遷移なしにURLや履歴は管理しつつ切り替えるSPAの構築が可能になりました。
フレームワークの登場
フロントエンドでできることが増えてきたことで、これまでサーバ側で行われてきたビューの処理が移動してくることになりました。それにより複雑化したフロントエンドを効率よく開発するためのフレームワークが誕生しました。
- Angular.js
- React
- Vue.js
ReactとFlux
- React : ReactはViewの開発をよりよくするためのアプローチ、UIごとにViewを分割し、複数のViewによって1つの画面を構成する
- Flux:Facebookが提唱したUIを持ったアプリを作るためのアーキテクチャ、またそのライブラリのこと。Viewでのアクション(ボタンクリックやテキストボックス入力などユーザ操作など)に応じてサーバにアクセスし、その結果をViewに反映させる一連の流れについてのアーキテクチャ
個人的な理解ではVue.jsは上記の2つを1つのVue.jsという考え方で実現しているが、Reactの場合はViewとデータフローというの2種類に分けて設計をしている。
ReduxはFluxの概念を拡張して扱いやすく設計されたデータフロー管理のためのライブラリ。
RxJS
JavaScriptでのイベントのハンドリングや非同期処理をラップし、扱いやすくするためのライブラリ
axios
Promise ベースの HTTP クライアント。API からデータを取得したり、APIにデータを送信する際に利用するライブラリ。
RxJS入門 | 第1回 RxJSとは | CodeGrid
BFF (Backends for Frontends)
フロントエンドとバックエンドの間にAPIアグリゲーションやそのキャッシュの用途などに挟む役割を持つアーキテクチャ、またはその実装のことを指す。
例えばモバイルとPCで出力結果を変えたい場合、そもそも叩くAPIの数や種類が違ったりする場合がある。このときにフロントエンドで叩くAPIの種類をハンドリングするよりもそれを管理するアグリゲーターを役割ごと(ここではモバイル用とPC用BFF)に用意するほうが管理が集約でき、通信数も抑えられる。
フロントエンドの範疇として対応することが多くGoで実装されたりNext.jsが使われることもある。
HTMLの生成手法
名前 | 説明 |
---|---|
CientSideRendering | クライアント(ブラウザ)のJSにて処理が行われ必要なリソースの取得→DOM生成→描画を行う処理のこと。クライアントで処理を行うため動的な更新や、リアルタイムの更新が可能な反面、クライアント側のNW環境やCPU性能によって描画速度が遅くなったり、何も表示されない帰還が発生するなどの課題もある。またSEOとしてもJSの実行をまたずに行われることもあるため、完全なページの評価を受けづらくOGPの生成にも難あり。 |
SPA:Single Page Application | 1つのURLの中でページ遷移を伴わない形でユーザにコンテンツを提供するスタイル。クライアントサイドレンダリングを用いて、ユーザのアクションの都度サーバ側からコンテンツを取得しブラウザにてその結果を反映している。 |
SSR:ServerSideRendering | クライアントからのアクセスに応じてサーバサイドで都度静的コンテンツを生成して返却するパターン。ユーザのアクションによってアクセス時の最新のデータを内包したデータを返すことが可能となる。そのため生成時間=ユーザの待ち時間となるのでUXに影響するため使いどこを考えること |
SSG:ServerSideGeneration | あらかじめサーバサイドにて静的なコンテンツを生成しておく手法。ブログの記事一覧やヘルプページなど、更新時にその結果を静的コンテンツとして生成しておけばよいため、ページをダウンロードすればすぐ表示が可能。一方でページ自体が大きくなる傾向にあるため、ダウンロード速度が遅いと最初の表示が遅くなる場合がる。SEO的には静的コンテンツのため問題無し。 |
SPA
TwitterやFacebook、Slackなどで使われている技術です。ユーザがリロードすることなく次々に新しい情報が送られてきます。厳密に言うとSinglePageというよりはクライアントサイドレンダリングを多用して、ホームページにてタイムラインを動的に更新しているという感じです。
Twitterを見てみると定期的にコンテンツの取得APIを叩いている(subscribe)しているのが見受けられます。
正式なSPAが体験できるサイト→空雲リファレンス
SSR
SSRの導入事例
ここでいうSSRはサーバサイドでレンダリングをするという意味以上に、Next.jsにおけるリクエスト都度ページを生成する機能という意味合いも持っています。一般用語でもあるしNext.js用語でもあります。
都度ページを生成するので速度的に問題になる事が多く限定的なページでしか使用されない。例えばユーザごとに異なるマイページなどがそれにあたります。また予想でしか無いが映画館や飛行機の座席情報についてもSSRかCSRが使われていると思われる。
SSG
一方で速度の早いSSGですが以下のサイトではこのような課題も取り上げられています。
Next.js の Incremental Static Regeneration を理解する
- 静的なページを生成する際にページ数が多いとビルドに時間がかかる
- 1 度しかビルドしないので、再度すべてのページをビルドし直さないと内容が更新されない
これに対応したISR(Incremental Static Regeneration)というものがNext.jsで登場しており次の動作で解決しています。
- アクセス時に初めて生成されるので初回ビルドが高速
- ISR でページ生成後も再度アクセスがあった際に次回以降の内容をビルドするので内容が更新される
ISRは指定秒数以後は新しいページが作成されるためいいとこ取り感があるが、かつてのS3のように結果整合性として成立しているためタイミングによっては古い情報が参照される可能性があるため使い所に注意すること。
JAM Stack
Webサイトの構成をJavaScript、API、MarkUp言語で成立させるというコンセプト。ブラウザのコンテンツは従来のマークアップ、ブラウザ内での動作はJS、外部リソースへのアクセスはAPIってことですね。
類似概念としてLAMPを紹介している記事もありましたが、正直別物だと思っていてあっちはインフラレイヤを含めた話なんですよね。JAMでいってAPIも裏側はなんかしらのインフラなりSaaSがあるわけなのでそれを扱っていない段階で同じ領域にはいないわけです。というのが自分の理解になります。
まあでもJAMの言いたいことはわかりやすいですね。たかだかHTMLを表示するだけなら置いといてHTTPで引っ張ればよかったものが、より便利でよりリッチな体験をっていう流れにのまれてJSだー、APIだーってなってきたのは面白さを感じます。
ホスティングの選択肢
静的SSRの場合は生成したHTMLやJSをおいておくだけで良いためWebサーバとしては安価なホスティングサービスを使えば良い。
- Firebase
- GitHub
- S3 (Amplify 使うケースも
- Netlify (個人でやるにはいいとか
- Vercel Next.jsをそのまま動かせる、結構いいらしい