modern-frontend-design-pattern

© 2023, Amazon Web Services, Inc. or its aﬃliates. All
rights reserved. © 2023, Amazon Web Services, Inc. or its aﬃliates. All rights reserved. モダンフロントエンドデザインパターン〜優れた UX を実現するには〜 Daisuke Awaji / 淡路⼤輔（@gee0awa） D - 5 Amazon Web Services Japan G.K. Solutions Architect

rights reserved. Daisuke Awaji Amazon Web Services Japan Solutions Architect • ガバメントクラウドを利⽤されるお客様のご⽀援を担当 UI/UX, Modernization, Mobile App など • 好きな AWS サービス AWS AppSync, AWS Lambda, Amazon CloudFront 3 AWS AppSync AWS Lambda Amazon CloudFront @gee0awa

rights reserved. ・様々なフロントエンドのレンダリング⼿法を理解する・ユーザ体験（UX）を最適化するための⼿段として把握する・on AWS での実装ポイントを知るこのセッションのゴール

© 2023, Amazon Web Services, Inc. or its affiliates. All
rights reserved. UI (User Interface) UX (User Experience)

rights reserved. UI (User Interface) UX (User Experience) ウェブサイトやアプリにおけるボタンや画像など⽬に⾒えているすべての情報製品やサービスを利⽤する中で得られるユーザ体験

rights reserved. UI (User Interface) UX (User Experience) アプリの操作性に関する（狭義の）ユーザ体験サービス全体としての（広義の）ユーザ体験

rights reserved. 開発者が⾼速な仮説検証を⾏うための環境や習慣、⽂化 Developer Experience - 開発者体験 UX (User Experience) DX (Developer Experience)

rights reserved. ・なかなか表⽰されず真っ⽩な画⾯のまま・ボタンをタップしても反応しない・・・・初回ロードやページ遷移時にガタガタとコンテンツが読み込まれる・ブラウザバックでスクロール位置が変わってしまったウェブサイトにおけるユーザ体験の悪い例

rights reserved. Google の検索エンジンのアルゴリズムを最適化するための指標 Google Page Experience Signal Loading Largest Contentful Paint (LCP) Interactivity First Input Delay (FID) Visual Stability Cumulative Layout Shift (CLS) Mobile Friendly HTTPS No Intrusive Intersitials https://developers.google.com/search/blog/2021/08/simplifying-the-page-experience-report?hl=ja

rights reserved. Google の検索エンジンのアルゴリズムを最適化するための指標 Google Page Experience Signal Loading Largest Contentful Paint (LCP) Interactivity First Input Delay (FID) Visual Stability Cumulative Layout Shift (CLS) Mobile Friendly HTTPS No Intrusive Intersitials Core Web Vitals https://developers.google.com/search/blog/2021/08/simplifying-the-page-experience-report?hl=ja

rights reserved. ページ内で⼀番⼤きなコンテンツが表⽰されるまでの時間 Largest Contentful Paint (LCP) Largest Content geeawa.io/blog/abc 最も⼤きなコンテンツ Images Image tags Video thumbnails Background image with CSS Text elements, headings etc.. https://web.dev/lcp/

rights reserved. 2.5 秒以内のロードを⽬指すことが推奨されている Largest Contentful Paint (LCP) GOOD NEEDS IMPROVEMENT POOR LCP Largest Contentful Paint 2.5 sec 4.0 sec

rights reserved. ページ内のいずれかの部分が画⾯上にレンダリングされるまでの時間 First Contentful Paint (FCP) https://web.dev/fcp/ geeawa.io/blog/abc geeawa.io/blog/abc Largest Content geeawa.io/blog/abc geeawa.io/blog/abc FCP LCP First Contentful Paint Largest Contentful Paint

rights reserved. 1.8 秒以内のロードを⽬指すことが推奨されている First Contentful Paint (FCP) GOOD NEEDS IMPROVEMENT POOR FCP First Contentful Paint 1.8 sec 3.0 sec

rights reserved. geeawa.io/blog/abc ユーザが最初にページを操作してから、ブラウザが応答するまでの時間 First Input Delay (FID) https://web.dev/lcp/ geeawa.io/blog/abc

rights reserved. ユーザが最初にページを操作してから、ブラウザが応答するまでの時間 First Input Delay (FID) html css js js image, etc… Network request Main thread task Navigation Start Styles are loaded and Browser can paint content Main thread is idle FCP TTI (Time to Interactive) Network Requests Main Thread Interactive !! FID Browser can respond to first user input Browser receieves ﬁrst user input

rights reserved. 良好なユーザ体験を提供するために、100 ms 以下を⽬指す First Input Delay (FID) https://web.dev/fid/ GOOD NEEDS IMPROVEMENT POOR FID First Input Delay 100 ms 300 ms

rights reserved. ページのレイアウトにどれだけズレが⽣じたかを数値化したもの Cumulative Layout Shift (CLS) https://web.dev/i18n/ja/cls/

rights reserved. ズレが⽣じる要素のビューポート領域の割合や距離によって数値化 Cumulative Layout Shift (CLS) https://web.dev/i18n/ja/cls/ GOOD NEEDS IMPROVEMENT POOR CLS Cumulative Layout Shift 0.1 0.25

rights reserved. Core Web Vitals ウェブサイトにおけるユーザ体験の指標 TTFB Time To First Byte ブラウザが最初のバイトを受信するまでの時間 FCP First Contentful Paint ブラウザが最初の要素を表⽰するまでの時間 LCP Largest Contentful Paint ブラウザが最も⼤きい要素を表⽰するまでの時間 TTI Time To Interactive ユーザの⼊⼒を即座に応答できるようになるまでの時間 CLS Cumulative Layout Shift ページレイアウトのズレを定量的に数値化 FID First Input Delay ユーザが⼊⼒をしてからブラウザが応答するまでの時間 ※ 2024年に FID ではなく、INP (Interaction to Next Paint) を Core web vitals の metric にしようとする動きもあります。

rights reserved. Developer Experience ウェブサイトにおける開発者体験の指標 ⚡ Fast Build Times ⾼速にアプリケーションをビルドデプロイしつづけたい " Low Server Costs サーバにかけるコストを削減したい ✨ Dynamic Content 動的なコンテンツをパフォーマンス良く提供したい ♻ Easy Rollbacks 以前のバージョンにロールバックしやすくしたい $ Reliable uptime アプリケーションを常に利⽤可能な状態で維持したい % Scalable Infrastructure 容易にスケールするインフラを⽤意したい

rights reserved. アプリケーションやビジネスの特性に応じてユーザ体験・開発者体験を最適化するレンダリング⼿法を採⽤する Rendering Pattern https://web.dev/rendering-on-the-web/#rehydration-issues ・・・

rights reserved. 最⼩限の HTML のみがサーバによって返却されるページを表⽰するロジック、データフェッチ、ルーティングはブラウザで実⾏される JavaScript によって処理する Client-side Rendering (CSR) geeawa.io/blog/abc geeawa.io/blog/abc JS loads 最⼩限の HTML

rights reserved. HTML “skeleton” ships <html> <head> <titile>Website</title> <link href="/styles.css" rel="stylesheet"/> </head> <body> <div id="root"></div> <script src="/bundle.js"></script> </body> </html> geeawa.io/blog/abc

rights reserved. Render blocking JS <html> <head> <titile>Website</title> <link href="/styles.css" rel="stylesheet"/> </head> <body> <div id="root"></div> <script src="/bundle.js"></script> </body> </html> geeawa.io/blog/abc

rights reserved. DOM created entirely with JS <html> <head> <titile>Website</title> <link href="/styles.css" rel="stylesheet"/> </head> <body> <div id="root"><div class=“…”>…</div></div> <script src="/bundle.js"></script> </body> </html> geeawa.io/blog/abc

rights reserved. アプリケーションシェルとなる HTML を取得 Client-side Rendering (CSR) - Process GET / GET /bundle.js render (app) Network Requests Main Thread First Paint (FP) 背景⾊やヘッダーなど視覚的に何かが表⽰されたタイミング First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. 部分的なコンテンツのみを表⽰（空⽩ページ or Loading Indicator） Client-side Rendering (CSR) - Process GET / GET /bundle.js render (app) Network Requests Main Thread FP First Paint (FP) 背景⾊やヘッダーなど視覚的に何かが表⽰されたタイミング First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. 意味のあるコンテンツがレンダリングされる Client-side Rendering (CSR) - Process GET / GET /bundle.js render (app) Network Requests Main Thread FCP FP First Paint (FP) 背景⾊やヘッダーなど視覚的に何かが表⽰されたタイミング First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. ユーザのインタラクティブな操作に応答できる Client-side Rendering (CSR) - Process GET / GET /bundle.js render (app) Network Requests Main Thread FCP TTI FP First Paint (FP) 背景⾊やヘッダーなど視覚的に何かが表⽰されたタイミング First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. ページの表⽰までの時間は JavaScript のバンドルサイズに依存 Client-side Rendering (CSR) - Process GET / GET /bundle.js render (app) Network Requests Main Thread FCP TTI FP First Paint (FP) 背景⾊やヘッダーなど視覚的に何かが表⽰されたタイミング First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. Report: State of JavaScript Bytes 2011 2017 2023 ~ 100KB ~ 300KB ~ 500KB https://httparchive.org/reports/state-of-javascript Webページからリクエストされた JavaScript のサイズ（中央値）

rights reserved. CSR におけるパフォーマンスの最適化・Code Splitting / コード分割・Lazy Loading / 遅延読み込み・CDN におけるコンテンツキャッシュ

rights reserved. ページの表⽰までの時間は JavaScript のバンドルサイズに依存 Code Splitting, Lazy Loading GET / GET /bundle.js render (app) Network Requests Main Thread FCP TTI FP First Paint (FP) 背景⾊やヘッダーなど視覚的に何かが表⽰されたタイミング First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. Webpack, Rollup などのバンドラーを使って、ビルド時にコードを分割ページ表⽰に必要なコードだけを遅延読み込みさせる Code Splitting, Lazy Loading GET / render (app) Network Requests Main Thread FCP TTI FP GET /bundle1.js GET /bundle2.js GET /bundle3.js Lazy Loading First Paint (FP) 背景⾊やヘッダーなど視覚的に何かが表⽰されたタイミング First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. Client-side Rendering (CSR) Architecture Amazon S3 Amazon CloudFront Browser コンテンツキャッシュリクエスト HTML, CSS, JS Rendering OAC アクセス (Origin Access Control) API 実⾏データを取得 Amazon API Gateway AWS Lambda or GitHub AWS CodeCommit AWS CodeBuild デプロイソース管理ビルド

rights reserved. Cache-Control: max-age などのディレクティブヘッダによりブラウザの Private Cache や CDN の Public Cache が利⽤できます Private Cache vs Public Cache （オリジンサーバ） Cache !! Cache !! Private Cache Public Cache キャッシュサイズに制限がある点には注意︕ Amazon S3 Amazon CloudFront （CDN）ブラウザオブジェクトメタデータの例 Cache-Control: max-age=60（ブラウザ・CDN両⽅） Cache-Control: s-maxage=60 （CDNのみ）

rights reserved. 全てのコンテンツは CDN でキャッシュしつつ、ハッシュ付きファイルは、ブラウザのキャッシュも有効にする。 CSR するアプリのキャッシュ戦略 Private Cache （ブラウザ） Public Cache （CDN）キャッシュしないキャッシュするキャッシュするキャッシュする Un-Hashed File index.html, favicon.ico etc... Hashed ﬁle main.849234.js, main.809vsa.css etc.. index.html には、ハッシュ付きの静的コンテンツのパスを記載する（Cache Busting）デプロイ時には、CDN にキャッシュしているファイルの invalidate （キャッシュのクリア）を⾏う。デプロイ毎にハッシュは変わるため、ブラウザキャッシュに Hit しない場合は CDN のコンテンツを参照することができる。 <script defer="defer" src="/static/js/main.40280510.js"></script> <link href="/static/css/main.073c9b0a.css" rel="stylesheet" /> デプロイ Cache !! Cache !!

rights reserved. 46 Client Side Routing 実装時の注意点 React Router などを使⽤して Client Side Routing の実装をした際に、 /about などでブラウザのリロードをすると、403(access denied)となる Amazon CloudFront Amazon S3 /about 403 Error OAI アクセス (Origin Access Identiy) / 200 OK /index.html （Default root object）カスタムエラーレスポンスで 403 Error だった場合は index.html を 200 OK で返却することもできるが、実はキャッシュ最適化の観点ではバッドプラクティス

rights reserved. 47 CloudFront Functions による URL の書き換え CloudFront Functions でリクエスト URL を書き換えることで Edge Location のキャッシュヒット率を⾼める Amazon S3 Viewer Request Viewer Response Origin Request Origin Response CloudFront Functions CloudFront Edge Location キャッシュキャッシュがある CloudFront Regional Edge Location https://aws.amazon.com/jp/blogs/news/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale/ https://aws.amazon.com/jp/blogs/news/implementing-default-directory-indexes-in-amazon-s3-backed-amazon-cloudfront-origins-using-cloudfront-functions/ キャッシュ Lambda @Edge キャッシュがない Lambda @Edge /about /index.html / /index.html /static/js/main.123.js /static/js/main.123.js Rewrite URL!! ※ Amplify の場合はマネージドで URL の書き換え機能があります

rights reserved. Client-side Rendering - まとめ・アプリケーションシェルとなる /index.html に紐づく全ての Static Assets をクライアントにロードしてからレンダリング・全ての Static Assets が読み込まれるまで表⽰できない。・Code Splitting, Lazy Loading などを使⽤して最適化・CDN, Browser におけるキャッシュも有効

rights reserved. Server-side Rendering (SSR) ⾃体は、昔からあった技術なのになぜ再注⽬されている︖

rights reserved. ユーザ体験を向上するためには JavaScript が必要⼀⽅で、JavaScript のコード量が多くなるとユーザ体験が悪化ユーザ体験と JavaScript のジレンマ

rights reserved. Server-side Rendering (SSR) with Hydration

rights reserved. Typical client-side rendering with React

rights reserved. Server-side rendering with React

rights reserved. Typical client-side rendering with React

rights reserved. Typical client-side hydration with React

rights reserved. What is the Hydration? hydrate(HTML) SSR された⽂字列 HTML をクライアントでイベントを受け取れるよう⽣きた仮想DOMとして再開させること HTML (String) イベントハンドラーの「⽔」で「乾いた」 HTML に⽔を注ぐ renderToString(<App/>)

rights reserved. Meta Frameworks React.js Vue.js Svelte SSR with Hydration の実装を助ける Meta-Framework を採⽤する VuePress Elderjs JngleJS

rights reserved. Server-side Rendering(SSR) Architecture AWS Lambda (Render) Amazon CloudFront Browser API Gateway (for SSR) AWS Lambda (Backend) API Gateway (for Backend) https://github.com/aws-samples/react-ssr-lambda Data Sources (API, DB, File etc..) SSR (Server-side Render) Amazon DynamoDB 基本的なサーバサイドレンダリングの構成 ECS Amplify でも OK ※ Amplify Hosting は現在 Next.js の SSR に対応しています。 App Runner EC2 Amazon Aurora or etc…

rights reserved. Server-side Rendering(SSR) Architecture Amazon CloudFront Browser AWS Lambda (Backend) API Gateway (for Backend) https://github.com/aws-samples/react-ssr-lambda Data Sources (API, DB, File etc..) SSR (Server-side Render) Amazon DynamoDB Lambda@Edge によるレンダリング Amazon Aurora or etc… ※ Lambda@Edge の Node ランタイムバージョン、実⾏時間、レスポンスサイズ 1MB 制限に注意 Lambda@Edge (Render)

rights reserved. FCPは短縮できるが、TTI は何も変わらないむしろ、First Input Delay (FID) を誘発しやすくなることも SSR with Hydration - Process Network Requests Main Thread FID TTI GET /bundle.js Hydration GET / FCP サーバでのデータフェッチレンダリング First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング Fist Input Delay (FID) ユーザの操作に対して応答されるまでの時間

rights reserved. SSR with Hydration – まとめ TTFB Time To First Byte ブラウザが最初のバイトを受信するまでの時間 FCP First Contentful Paint ブラウザが最初の要素を表⽰するまでの時間 LCP Largest Contentful Paint ブラウザが最も⼤きい要素表⽰するまでの時間 TTI Time To Interactive ユーザの⼊⼒を応答できるようになるまでの時間 CLS Cumulative Layout Shift ページレイアウトのズレを定量的に数値化 FID First Input Delay ユーザが⼊⼒をしてからブラウザが応答するまで

rights reserved. ・サーバでデータフェッチが完了しないと、HTMLが返却できない・全ての JavaScript がロードされるまで Hydration が始まらない・Hydration が終了するまで interactive にならない SSR with Hydration の課題

rights reserved. Streaming HTML Server ユーザがクリックした箇所やビューポートを優先して Stream で返却サーバサイドでデータフェッチが終わった部分から順番に表⽰できる

rights reserved. SSR + Hydration では CSR と⽐べて TTI に変わりがなかった問題を克服 Streaming HTML - Process GET / GET /bundle.js Network Requests Main Thread FCP TTI First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. SSR + Hydration では CSR と⽐べて TTI に変わりがなかった問題を克服 Streaming HTML - Process GET / GET /bundle.js Network Requests Main Thread FCP TTI 必要に応じて Stream 読み込み First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. SSR with full hydration SSR with partial hydration Selective Hydration 必要なときに必要なものを、部分的に Hydration する

rights reserved. Next.js による実装例 React の Suspense コンポーネントを利⽤することで Streaming HTML, Selective Hydration の恩恵を得る import { Suspense } from 'react'; export default function App() { return ( <Layout> <Header /> <SideNav /> <Suspense fallback={<Loading />}> <Articles /> </Suspense> </Layout> ) } https://ja.legacy.reactjs.org/docs/code-splitting.html geeawa.io/blog/abc Loading…

rights reserved. import { Suspense } from 'react'; export default function App() { return ( <Layout> <Header /> <SideNav /> <Suspense fallback={<Loading />}> <Articles /> </Suspense> </Layout> ) } Next.js による実装例 React の Suspense コンポーネントを利⽤することで Streaming HTML, Selective Hydration の恩恵を得る https://ja.legacy.reactjs.org/docs/code-splitting.html geeawa.io/blog/abc

rights reserved. Rendering Patterns Server-side rendering Client-side rendering SSR with hydration

rights reserved. Rendering Patterns Server-side rendering Client-side rendering SSR with hydration Pre-rendering （SSG）

rights reserved. Static Site Generation (SSG) Server-side Rendering (SSR) Static site Generation (SSG) or pre-rendering Rendering…

rights reserved. Static Site Generation (SSG) Server-side Rendering (SSR) Static site Generation (SSG) or pre-rendering Rendering… Pre-renderd index.html about.html article.html

rights reserved. Server-side Rendering (SSR) と⽐べて、FCP と TTI の両者を短縮する Static Site Generation - Process GET / Network Requests Main Thread FCP TTI SSR の場合 First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. Server-side Rendering (SSR) と⽐べて、FCP と TTI の両者を短縮する Static Site Generation - Process GET / Network Requests Main Thread FCP TTI サーバでのデータフェッチやレンダリング処理時間も改善 SSG の場合 First Contentful Paint (FCP) 何らかユーザにとって意味のある DOM 要素が表⽰されたタイミング Time to Interactive (TTI) ユーザの操作をインタラクティブに受け付けることができるタイミング

rights reserved. Static Site Generation Architecture Amazon S3 Amazon CloudFront Browser コンテンツキャッシュ ①リクエスト ② HTML, CSS, JS Rendering or GitHub AWS CodeCommit AWS CodeBuild デプロイソース管理ビルド OAC アクセス (Origin Access Control) Data Source API, DB ビルド時にデータを取得して全ページを⽣成する

rights reserved. ・レンダリング済みのファイルを CDN にキャッシュ可能・コンテンツの表⽰速度に関して⾔えば、最も優秀な選択肢・ブログ、ドキュメント、製品ページなど静的なページに特化して利⽤ Static Site Generation の得意とする領域

rights reserved. ・静的なコンテンツに限られる・ビルド時にすべてのページを⽣成しなければならない参考）タイムアウト時間 CodeBuild: 8時間, GitHub Actions: 6時間・ビルド時に⼤量の API リクエストが発⽣する Static Site Generation における注意点

rights reserved. Rendering Patterns Server-side rendering Client-side rendering SSR with hydration Pre-rendering （SSG）

rights reserved. Rendering Patterns Server-side rendering Client-side rendering SSR with hydration Pre-rendering （SSG） Incremental Static Regeneration

rights reserved. SSG 的に全てをビルド時に⽣成するのではなく、ページに優先度をつけるリクエストされてから⽣成したページをキャッシュしようという考え⽅ Incremental Static Regeneration (ISR) Static Site Generation (SSG) Incremental Static Regeneration (ISR) ビルド時に1000ページだけ⽣成するリクエストが来たページは SSR してキャッシュに載せるリクエストが来ないページは⽣成しない https://www.smashingmagazine.com/2021/04/incremental-static-regeneration-nextjs/

rights reserved. Cache Control における stale-while-revalidate と同様の⽅法でキャッシュする以下は、60秒ごとに revalidate する場合 Incremental Static Regeneration (ISR) 0 s 60 s v1 Generate Page v2 Generate New Page and Update Cache v1 v1 v1 Serve from Cache v1 Return Stale Page v2 Serve from Cache v2 v2 （revalidate するまでは古いコンテンツを返す）

rights reserved. Next.js のホスティングの選択肢 Amazon EC2 AWS Fargate AWS App Runner Computing AWS Amplify AWS Lambda Amazon CloudFront Amazon S3 Serverless Amplify Hosting

rights reserved. Next.js によって SSG されたページは CloudFront にキャッシュしつつ Lambda@Edge を使⽤して SSR を⾏うハイブリッドなアプローチ Serverles Next.js CDK Construct https://www.npmjs.com/package/@sls-next/cdk-construct ・CloudFront を CDN として利⽤・静的ファイルを S3 でホスティング・Lambda@Edge で API, SSR ・ISR する場合は、SQS も ※ Lambda@Edge の Node ランタイムバージョン、実⾏時間、レスポンスサイズ 1MB 制限に注意 ※ 最新の Next.js 13 の機能全ては利⽤できない Nex.js 12 までの⼀部の機能をサポート

rights reserved. Next.js のビルドアーティファクト（.next/*）を、 Lambda@Edge にデプロイする単位にパッケージングする @sls-next/lambda-at-edge によるビルド https://www.npmjs.com/package/@sls-next/lambda-at-edge import { Builder } from "@sls-next/lambda-at-edge"; const builder = new Builder(".", "./build", { args: ["build"] }) Lambda@Edge (API) Lambda@Edge (SSR) Lambda@Edge (ISR) Lambda@Edge (Image Optimize) Next.js のビルド済みファイル

rights reserved. Is Serverles Next.js dead?

rights reserved. Next.js のビルド成果物をデプロイ可能な単位にパッケージングする ↑ ここまでは Serverless Next.js と⼀緒 Next.js 13 のすべての機能をサポートすることを⽬標としている Streaming HTMLは未サポート Amplify という選択肢もあるが、よりオープンに、よりサーバレスにがコンセプト Open Next https://open-next.js.org/ Vercel は素晴らしいですが、すべてのインフラストラクチャがAWS上にある場合、それは良い選択肢ではありません。 AWSアカウントでホスティングすると、バックエンドとの統合が容易になります。そして、それは Vercel よりもずっと安いです。

rights reserved. AWS Lambda Web Adapter https://github.com/awslabs/aws-lambda-web-adapter AWS Lambda で Web アプリを実行するための OSS ツール

rights reserved. Example – Next.js on Lambda install Lambda Adapter AWS Lambda Web Adapter をインストールするには１行追加するだけ

rights reserved. AWS Lambda Response Streaming レスポンスデータが利用可能になった時点で返却することで TTFB を改善する最大 20MB のレスポンスペイロードをサポート Response streaming Next.js の Streaming HTML も動作します

rights reserved. Response streaming Demo Next.js の Streaming HTML を AWS Lambda Response Streaming で https://github.com/awslabs/aws-lambda-web-adapter/tree/main/examples/nextjs-response-streaming Header など、すぐに表⽰できるものは即座に返却しつつ動的なコンテンツはサーバサイドで準備できてから順次返却する https://aws.amazon.com/jp/blogs/news/implementing-ssr-streaming-on-nextjs-with-aws-lambda-response-streaming/ サンプルソースブログ

rights reserved. サポートされている機能 Amplify Hosting ・Server-side rendered pages (SSR) ・Static pages ・API routes ・Dynamic routes ・Catch all routes ・SSG (Static generation) ・Incremental Static Regeneration (ISR) ・Internationalized (i18n) sub-path routing ・Internationalized (i18n) domain routing ・Middleware ・Environment variables ・Image optimization. サポートされていない機能・Edge API routes ・On-Demand ISR ・Next.js 13 app directory (beta) ・Streaming HTML ・Selective Hydration よりシンプルに利⽤するなら Amplify に頼ってしまう⽅法も AWS Amplify ※ 2023年6⽉時点では Next.js 以外の SSR はサポートされませんのでご注意ください

rights reserved. Computing Next.js 13 (latest) の機能を全て使いたい場合 React Server Components, SSR Streaming, Server Actions など Amazon EC2 AWS Fargate AWS App Runner

rights reserved. Next.js のホスティングの選択肢 Amazon EC2 AWS Fargate AWS App Runner Computing AWS Amplify AWS Lambda Amazon CloudFront Amazon S3 Serverless Amplify Hosting

rights reserved. Rendering Patterns Server-side rendering Client-side rendering SSR with hydration Pre-rendering （SSG） Incremental Static Regeneration HTMLの⽣成元サーバービルドサーバクライアント Hydration - Selective Hydration Streaming HTML - SEO対策クローラークローラは読み込み可能制限ありキャッシュ最⼩限ページごとにキャッシュ可能全載せ FCP : TTI FCP = TTI FCP << TTI FCP = TTI FCP < TTI Hydration はしないが JavaScript を最⼩限にする戦略ビルドサーバ + サーバー

rights reserved. モダンフロントエンドのその先へ・SSR を基本とし、JavaScriptを最⼩化する・部分的に触りたいコンポーネントを狙って Hydration する・アイランドアーキテクチャ・Hydration は必要ない。Resumable という思想。・ハンドラだけをDOMに⼊れておいて、イベントが起きたタイミングで JS をダウンロードする・element ではなく、window に対してイベントを設置しておくことで実現している

rights reserved. Let’s try https://github.com/awslabs/aws-lambda-web-adapter/tree/main/examples/nextjs-response-streaming ・Next.js を AWS Lambda Response Streaming で動かしてみる https://github.com/aws-samples/amplify-nextjs-ssg ・Next.js の SSR, SSG 機能を Amplify で動かしてみる https://github.com/aws-samples/react-cors-spa ・React を CloudFront, S3 にデプロイする

rights reserved. Everything in software architecture is a trade-oﬀ The First Law of Software Architecture Fundamentals of Software Architecture

modern-frontend-design-pattern

modern-frontend-design-pattern

More Decks by g-awa

Other Decks in Programming

Featured

Transcript