#dist40 柴田 和祈 Webフロントエンドの進化と Jamstackアーキテクチャの変遷

自己紹介 2 #dist40 柴田 和祈 / Kazuki Shibata @shibe97 株式会社microCMSの共同創業者 / CXO 元デザイナー兼フロントエンドエンジニア

ご利用 企業数 ご契約 継続率 以上 99％ 6,000社 以上 編集者も使いやすい 日本製ヘッドレスCMS 3

4 #microcms_meetup

5 What’s Jamstack? ※以前、公式サイトに載っていた図

- 技術の移り変わりによって、公式サイト（jamstack.org）の中身も変化している - Netlify社が作り出した概念のため、営利的に解釈は変化していくものと捉えている（個人的感想） - jamstack.wtfでもVercelの登場によりJamstackの意味合いは曖昧になってきたと記載がある - フロントエンド・エッジ技術は従来のJamstack定義のはるか先まで進んでしまっている 6 Jamstackの曖昧さ

歴史を辿りながら Webフロントエンドの進化を 見ていきましょう 7

8 SPA（Single Page Application）の登場 - JavaScriptのXHR（XMLHttpRequest）を利用して、クライアントサイドでのページ遷移を可能にした - 2005年2月「Ajax: A New Approach to Web Applications」論文 - ページ遷移時に真っ白な画面で待つ必要がなくなり、ユーザー体験が向上した - サーバーサイドで行っていたロジックがクライアントサイドに移り、JS実装の複雑性が増した - MVC系フレームワークの登場 - Backbone, Angular, Vue, React, etc...

9 SSR（Server Side Rendering）の登場 - 従来のSSRではなく、SPA込みでのSSRの話 - サーバーサイドからクライアントサイドに各種状態の連携（ハイドレーション） - SPAの下記の問題点を解決 - 最初に大きなバンドルJSを読み込む必要があるため、初期ロードが遅い問題 - SSRと比較するとクローラーにIndexされづらい問題 - Next, Nuxtが登場 - SSRの難しいところを全部吸収したフレームワークとして人気に

10 SSG（Static Site Generate）の登場 - モダンJSフレームワークによるサイト全体の静的化が人気に - Nuxt v2.13でFull Static Generationが登場し、ページ遷移時のAPIレスポンスも静的化 - もちろんハイドレーションしてSPAとしても動作する - リンク先のプリフェッチも導入され、超高速サイトが作れるようになる

11 新たなホスティングサービスの登場 - 静的ビルドしたファイル群をCDNから配信できる サービスが相次いで登場 - Netlify / Vercel / Amplify Console / etc… - Atomic Deploys - すべてのコード、アセットが一気に更新されるため、 ウェブサイトが部分的に更新された状態にはならない - FTPアップロードの問題を解決 - ここでJamstackに火が点いた

- APIでコンテンツ管理ができるヘッドレスCMSが登場 - Jamstackで静的ページを作れるようになったが、非エンジニアが運用できない という問題を解決 12 ヘッドレスCMSの登場

- オリジンサーバーへの物理的な通信遅延を解決するための分散型サーバーのネットワーク - CDNの一部として機能する個々のサーバーをエッジサーバーと呼ぶ 13 CDN（Content Delivery Network） オリジンサーバー ユーザー エッジサーバー 50ms 200ms エッジサーバー エッジサーバー

- ビルドが遅い - 1ページ更新すると全ページビルドが走ってしまう - 大量のページがある場合、1時間以上かかることも・・・ - 速報性のあるページや、時間きっかりに公開したいページとの相性が良くない - CMSのプレビューの実装を自前で行う必要がある 14 Jamstackの課題

- CDNのキャッシュが古い or 無い場合はバックグラウンドでデータを取りにいく - Stale While Revalidate という仕組み - ページ更新時も全体ビルドが不要になり、ビルド時間の問題は解決 - revalidate=1などとすれば、時間きっかりもまぁ問題なしと言える - Next + Vercel 時代に突入 15 ISRの登場

16 ISRの仕組み（キャッシュが有効な場合） オリジン ユーザー エッジ ①リクエスト ②キャッシュ返却

17 ISRの仕組み（キャッシュが古い場合） オリジン ユーザー エッジ ①リクエスト ②キャッシュ返却 ③リクエスト ④キャッシュ更新 キャッシュが古いかどうかは revalidateTimeで判断 一度古いキャッシュが返却される 二度目以降のアクセスで更新されたキャッシュが返却される

18 ISRの仕組み（キャッシュがない場合） オリジン ユーザー エッジ ①リクエスト ④キャッシュ返却 ②リクエスト ③キャッシュ更新 キャッシュがない場合は返却する ものがないので取得しに行く

- ルーティングごとにレンダリング方式を変えられるハイブリッド方式が登場 - 記事など大量ページがあり、更新も多い部分はSSR or ISR - 会社概要ページなど書き換えが極めて少ないページはSSGなど - 実装時はサーバー、クライアントのどちらで処理が動いているのかをよく考える必要がある - 最近のフレームワークはだいたいハイブリッドな流れに向かっている - Next, Nuxt, SvelteKit, Astro, etc 19 ハイブリッド方式

結果整合性 20 結果整合性と強整合性 強整合性 全ての更新が最終的には全ての参加者に伝播するこ とを保証する。 → 大規模な分散システムに向いている 全ての読み取りが最新の書き込みを常に反映する という保証する。 → 絶対的な制御が必要なシステムに向いている - SNS - メディア系 - 銀行などの金融系サービス - 航空予約システム - 在庫管理システム SSRやCSRはこちら SSGやISRはこちら

- ページ内でも静的部分と動的部分を同居させることができる - 静的部分を海、動的部分を島としたイメージ - Deno FreshやAstroで採用されている
 - 部分的なハイドレーションが可能
 - 必要なタイミングでJSがロードされる
 - スクリーンサイズが○○○px以下になったタイミング
 - ビューポートに入ったタイミング
 - etc
 21 アイランドアーキテクチャ https://docs.astro.build/ja/concepts/islands/

- アイランドアーキテクチャに近い - サーバーサイドだけで動作させるコンポーネント - useState等のReact Hooksが使えない - サーバーで処理する分、クライアントに渡すバンドルサイズを削減できる - 表示系ライブラリの読み込み（highlight.jsなど） - コンポーネント定義 - 最近のNext.js 13 App Routerではこの辺りの知識が必須 - より細かい単位での制御へ 22 RSC（React Server Components）

- エッジは静的コンテンツをキャッシュするだけの場所ではなくなってきた - Cloudflare Workersの登場で潮の目が変わった - V8（JavaScript実行エンジン）を採用しているため、エッジ上でJavaScriptが動く - ただし、Node.js特有のAPI（fsなど）が使えない制約はあり - バンドルサイズの制約（1MBなど） - CPU runtimeの制約（10msなど） - Next.js の middleware もエッジ上にコードを展開できる 23 エッジコンピューティングの加速

- コード実行 - Cloudflare Workers - Remix, SvelteKit, qwik, Hono - CloudFront Functions - Vercel Edge Functions - etc - DB - Cloudflare D1（SQLite） - ストレージ - Cloudflare R2（オブジェクトストレージ） - Cloudflare Workers KV（Key - Value store） 24 エッジ上で動かせるものたち

フロントエンドアーキテクチャは エッジをできる限り活用する方向に 進化している 25

- Jamstackという概念は技術の進歩と共に曖昧になってきている - フロントエンドアーキテクチャはCDNをフル活用する方向に進化している - 静的ファイルだけでなく、あらゆる処理・通信がCDN上で行われるようになってきている - できる限りレイテンシをなくしつつ、整合性の取れたアプリケーションを作るためにエンジニアに 求められる知識は益々増加している 26 まとめ

Thanks :) 27 #dist40 https://discord.gg/K3DPqw4EJ2 @micro_cms