Webフロントエンドの進化とJamstackアーキテクチャの変遷

DIST.40 「Jamstackの実際とミライ」での発表資料です。
https://dist.connpass.com/event/284922/

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

4. 4
   #microcms_meetup
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

21. - ページ内でも静的部分と動的部分を同居させることができる
    - 静的部分を海、動的部分を島としたイメージ
    - Deno FreshやAstroで採用されている

    - 部分的なハイドレーションが可能

    - 必要なタイミングでJSがロードされる

    - スクリーンサイズが○○○px以下になったタイミング

    - ビューポートに入ったタイミング

    - etc

    21
    アイランドアーキテクチャ
    https://docs.astro.build/ja/concepts/islands/
    

    View Slide

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

    View Slide

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

    View Slide

24. - コード実行
    - 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
    エッジ上で動かせるものたち
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide