NextでのCMS作り所感

早速ですが、
CMSの特徴からみてみましょう

• 外部公開しない(OGP＋SEO配慮不要)
• データ更新が頻発
• 多数のページのレーアウトは同様
• パーフォースの優先度は比較的に高くない
• ページの滞在時間長い

という特別なウェブアプリであって、

Next13が推奨するのStatic RenderingとDynamic Rendering以外、

SPA＋CSRの仕組みもおすすめです。

先に二つのアーキテクチャの特性を見ておきましょう。

① SPA + CSR　（自炊）

next exportによって静的なHTMLとJSバンドルを生成し、S3に置き、

ユーザーのブラウザがHTMLとJSを受け取った後に、ブラウザにて、

コンテンツを取得し描画するような仕組みです。

必要なものをブラウザに集めて、ページを生成します

（原材料を集めて自炊するイメージ）

② SR/DR(旧：SSG/SSR)　（レストラン）

Nextサーバーでコンテンツ取得して、

HTMLを生成、描画した後にブラウザに送るような仕組みです

	SPA+CSR	SR/DR
Request発信元	ブラウザ	Nextサーバー
Cache保存元	ブラウザ	Nextサーバー

Static Renderingの場合　※以下SR

ブラウザが取ってくるのはビルドの際に既に生成してあったHTMLです。
（レストランに行くとすぐ出してくれるお茶とか）

Dynamic Rendering　※以下DR

ブラウザが該当するURLをアクセスして、リクエスを出した後に、Nextサーバー内で作成し、それからブラウザに渡せます。
（注文してから作るメニューのイメージ）

もちろんSRとDRを混在することは可能です

※Dynamic Functionsを使うことで、あるRouteをSR→DRにさせることもできる。

評価軸

• ユーザー視点

  • 下記の三つの方面ともSR/DRの方が優秀です
    • FCP
    • リクエスト数
    • 資材(HTML,JS)サイズ

  理論上SR/DRを採用することでパーフォマンス向上することができる、

  兼ねてSEOを配慮すると、ToC向けのサービスであれば、迷いなくSR/DRを選択します。

  • ページに長時間滞在し、データ操作を行うというシーンで考えると、毎回route遷移する際に、ただデータを取得しにAPIを叩く、つまりデータのやり取りだけ発生します、こう考えるとCMSに相応しいのはSPAかも知りません。

• 開発者視点

  • SR/DR →FE・BE融合した開発

    NextサーバーでBFFの役を果たしてたので、FEとBEの壁なくし、BIG FEになる、スケジュールや突発対応もっと柔軟にできて、属人化↓

    仕組みを理解するに時間かかる、参入コスト↑

  • SPA→FE・BE分離した開発

    昔ながらの開発体制であり、技術スタックとスケジュールを別々に作することができる、関心分離ができた分、属人化↑

    仕組みがシンプルであり、参入コスト↓