新規開発時、技術スタックとしてフロントエンドをReactで構築することだけは決まった。
レンダリング方法はどれが正解なのかよく忘れるので毎回調べてしまう。
備忘録としてまとめようとしたけど、ほとんど個人的な感想ばかりになってしまったので、読み物として。
間違いあれば指摘してくださいmm
以下の表はReact(next.js)におけるレンダリング方法の違いである。
| 種類 | 説明 | 特徴 | 利用シーン | 向いているアプリケーション |
|---|---|---|---|---|
| SPA（Single Page Application） | ページを一度に読み込み、必要に応じてコンテンツを動的に更新 | - ページ遷移が速い - インタラクティブな操作が可能 - 初回ロードが重い - SEO対応が難しい |
- 高度なインタラクション - リアルタイム更新が多い |
- SNS、ダッシュボード、チャットアプリ |
| SSG（Static Site Generation） | 事前にページを静的HTMLとして生成し、ユーザーに配信 | - 事前ビルドで高速表示 - サーバー負荷が軽い - SEOに強い - 動的コンテンツには不向き |
- 頻繁に更新がないサイト - SEOが重要なサイト |
- ブログ、企業サイト、ドキュメンテーション |
| SSR（Server Side Rendering） | リクエストごとにサーバーでHTMLを生成し、ユーザーに配信 | - 初回表示が速い - 動的なデータに対応 - サーバー負荷が高い - リクエストごとにレンダリング |
- データが頻繁に更新されるサイト - リアルタイム性が重要なサイト |
- ニュースサイト、ECサイト、SNS |
| ISR（Incremental Static Regeneration） | 静的生成されたページを、バックグラウンドで段階的に更新 | - 静的生成の利点を活かしつつ、部分的に最新データを反映 - サイトのパフォーマンス維持 - 必要な部分だけを更新可能 |
- 頻繁に更新があるが、リアルタイムでなくてよいサイト - パフォーマンスが重要なサイト |
- ブログ、ECサイト、ニュースアプリ |
簡単にchatGPTで生成したものだが、個人的な見解をさらに記述する。
デプロイ先
next.jsのデプロイ先といえばvercelがデファクトスタンダードはご周知の通り。
しかし知名度的の問題か、今までEC2へデプロイを希望するケースが多かった。
AWSは料金が高額になりがちなので、オンプレ→AWS→オンプレ（もしくは別のクラウド）のように戻るケースもあるらしい。
vercel以外でnext.jsを使用する場合は色々設定が面倒なので、後で後述する。
SPA
そもそもnext.js使用しない選択はないだろうか？
自分がそうだったが、SPAは遅そうだからnext.jsにしとこう。SSRが良さそうなんてことになっていないだろうか。
SEO対策が特に必要なく、管理画面作るくらいであればSPAで十分だと思う。
速度面が問題にされているが、キャッシュで古いデータが表示された場合の対応など、それはそれでコストがかかる。
（そもそもパフォーマンスに問題がある場合、フロントの処理以前にもっと見直すべきところあると思う派）
page別にroutingしたい場合、tanstackRouter導入すればいいし、個人的に気に入っているのはURL欄が汚れないところ。（amazonとかrakutenとかマジ汚い）
SPAのデプロイ先候補：
Vercel, Netlify, GitHub Pages, Cloudflare Pages, S3
いずれも設定すればyarn deployコマンドなどを使用することにより、簡単にデプロイできるのでとにかく楽。
SSG
上記の表にあるように、主にブログとされているが、フルスタックフレームワークのnext.jsを使用しないと構築できないような巨大ブログ用ってことだろうか？？
2024年10月現在、最近gatsby聞かないけど、どうなったんだろう‥。
結局SSGは今まで使ってこなかったが、今後も使うことないような気がする。
SSR
next.js=SSRだと思っている。
getServerSidePropsを使用して、関数内のコードをサーバーで実行（サーバーリソースで計算）させることができる。
SSR使えばとにかく高速なページが作れると思っていたが、そういうわけでもない。
Link と ISR が引き起こす Next.js の過負荷
こちらの記事が有用なので、そのまま貼ります。
Linkコンポーネントにprefetchをつけると速くなる。→サーバー負荷がかかる。
AWSのサーバー代は超高額。
大企業でお金あります！ → OKそう
スタートアップで資金調達済み！ → OKそう
スタートアップでお金ありません！ → 無理そう
中小企業の営業で技術的なこと何もわかりません！ → 無理そう
以下小言。
Vercel以外にデプロイする場合は簡単だけど、nginxからリバースプロキシしてあげる必要あり。
vercelはEC2が元となっています。
EC2のサーバー環境は、普通のデータセンターと変わらないし、物理的には結構落ちるようだ。
アプリケーションが速くても、ネットワーク遅ければ同じと思う。
アプリケーションが速くても、非力なデバイスでアクセスされたら遅いと思う。
サーバーリソース上げたら速くなる、ケチったら遅い。つまりサーバー側で計算リソースを提供するか、クライアントに任せるか。
開発する分には、巣のreactの開発と特に違いはないと思う。
serverSidePropsが存在して、書いてるコードがどこで実行されているのか、意識するところが違うだけ。
そもそもサーバーサイドで計算させないといけないようなフロントのコードって何？
重たい計算とか言っているけど、それAPI側のリソース使えばいいんじゃないの？
APIで高額なサーバーを用意して、フロントで高額なサーバーを用意して、その他いろんなAWSのサービスを使って、AWS儲けすぎじゃね？
と思っている派。
ISR
Vercelにデプロイするのが大前提。
基本はSSGの挙動でgetStaticPropsを使用する。
これに加えてrevalidateを設定することにより、任意のタイミングでフェッチを行う。
潤沢な資金がある場合は、AWSで構築することも可能。
結論
next.jsを使用するか、どのレンダリング方法が良いかは案件次第＆デプロイ先次第だと思う。
エンジニア的には新しい技術をぶりぶり使って、いかにも有能さをアピールしたいところではあるが、クライアントのお財布事情を考えた方が自分の身入りにもなると思う。（サーバーにお金かかりすぎて、自分の報酬が減ったりすると嫌なので）