Next.js を SSG 化しようとして、最終的に React SPA に落ち着いた理由

BRANK

はじめにこんにちは。株式会社シータグで、自社サービスである BtoB 向けクラウド受発注サービス「受注ハック」の開発に携わっている ritsukei です。受注ハックのフロントエンドは、もともと Next.js を Amazon ECS Fargate 上でサーバーとして動かしていました。コストと運用負荷を見直す中で、最初に考えたのは「Next.js を残したまま SSG / static export に寄せる」ことです。ただ、検討を進めると問題は CDN やホスティングの選び方よりも、既存フロントエンドが持っている routing model そのものにあることが分かってきました。最終的には、React Router / Vite ベースの SPA（CSR）として再構成し、Cloudflare Workers Static Assets で配信する構成へ移行しています。この記事では、なぜ最初は SSG を目指していたのかなぜ途中で方針を変えたのか実際にどこで詰まり、どう整理し直したのかを中心に、移行の過程をまとめます。元の構成：Next.js on ECS Fargate移行前の構成は次のようになっていました。Frontend: Next.js on ECS FargateBackend: Go API server on ECS Fargateフロントエンドとバックエンドは最初から分離されており、Next.js を使ってはいたもの…