Next.jsをOpenNext+SSTを使用し、AWSにデプロイしてみた。
takecchiNext.jsをAWSに適切に乗せる為にopen-nextというデプロイツールを使ってみる。
ぱっと見結構よさそう。
検証内容
- ローカル環境とVercel、AWSで動きを比較
- pagesの検証
- SSG
- SSR
- AppRouterの検証
- RSC(React Server Component)
- RCC(Rreact Client Component)
takecchi正しくはOpenNextはAWS向けビルドツールで、
実際にデプロイするのはSSTやTerraformになるらしい。
SSTが推奨されていたので今回はSSTを使用してみる。
(スター数多いけど日本語記事あんまり見つからない)
takecchi今回使用するリポジトリ
検証用にリポジトリを作成した。3秒待機する作りになっています。
(よく考えたらfetchいらなかったかもしれない。でもfetchないと自動的に解釈されないんだっけ)
コードはこちらを参考に書きました。
URLパスは以下の通り
- /ssg ...
getStaticProps - /ssr ...
getServerProps - /rsc ...
React Server Component - /rcc ...
React Client Component
takecchiローカル環境で動かす
npm run build
npm run start
localhost:3000上で確認
SSG
ページ内遷移(Top->to SSG)
既に生成されたdocumentが返却されるので、待機時間は無し。ビルドには3秒かかるけど
SSR
ページ内遷移(Top->to SSR)
当然サーバーサイドで実行が走り、documentの返却までに3秒かかる。
RSC
ページ内遷移(Top->to RSC)
documentが返却されることは無く、ページ遷移は一瞬で終わり、サーバーサイドで処理されたコンポーネントが3秒後に戻ってくる。
RCC
ページ内遷移(Top->to RCC)
documentが返却されることは無く、ページ遷移は一瞬で終わり、クライアント側で処理されたコンポーネントが3秒後に表示される。
takecchiAWS環境で動かす
npx sst deploy
openNextを使用したビルドが行われ、それらが適切にAWSにデプロイされていく。
発行されたCloudFront URL上で確認
SSG
ページ内遷移(Top->to SSG)
既に生成されたdocumentが返却されるので、待機時間は無し。
ローカルと同様。
SSR
ページ内遷移(Top->to SSR)
当然サーバーサイドで実行が走り、documentの返却までに3秒かかる。
ローカルと同様。
RSC
ページ内遷移(Top->to RSC)
documentが返却されることは無いが、ページ遷移が3秒かかる。
ローカルと異なる。
おそらくLambda Streamに対応していないからと思われる。
RCC
ページ内遷移(Top->to RCC)
documentが返却されることは無く、ページ遷移は一瞬で終わり、クライアント側で処理されたコンポーネントが3秒後に表示される。
ローカルと同様。
takecchi別のツールも見つけた。
Stream対応有無が気になる
takecchiSSR Streaming を AWS Lambda Response Streaming で実装する
takecchiRSCの挙動が異なる件
やはりストリーミングに対応してないことが原因ぽい
動きはあるみたい。OpenNext採用が決まったタイミングで未解決なようであればプルリクエスト出したい。
takecchiストリーミングに対応したようなので改めて挙動は確認したい。
takecchilambdaについて
あげる先がlambda@edgeって書いてある気がするけど秒間リクエスト一万までしか捌けないのでは？と思ったけど事前or定期的にビルドしたS3資材返す仕組みだから捌けるか
edge: trueと明示的に指定した場合のみデプロイ先がlambda@edgeになるみたい。
takecchiメモ
next.config.jsでoutput: 'export'にしてるとnpx open-next buildでエラーになる。
恐らく.next/standalone配下に.next/serverが出力されないため？
takecchi実運用に耐えられるかはこちらで検証するものとする