Next.jsは必ずしも必要ではない
Reactアプリを構築する際、Next.jsは「とりあえずこれ」というデフォルトの選択肢になります。素晴らしいフレームワークですが、「とりあえず」が「必要」を意味するわけではありません。
不適切なプロジェクトにNext.jsを使用したことで、開発スピードが落ち、チーム内に摩擦が生じました。私たちが開発したのは、ダッシュボードやチャートを備えたデータ集約型の製品です。ほぼすべての画面がログイン後に表示されるものでした。
この種のアプリにおいて、サーバーサイドレンダリング（SSR）は価値を付加することなく、コストだけを増大させていました。
適切なツールは、何を作るかによって決まります。
コンテンツ重視のプロジェクト： • マーケティングサイト • ブログ • ストアフロント • ドキュメント • ここではNext.jsを使用してください。SEOが重要であり、コンテンツが静的だからです。
アプリケーション重視のプロジェクト： • 社内ツール • ダッシュボード • 管理パネル • SaaSコンソール • ここではViteベースのSPAを使用してください。これらのアプリは認証の後にあり、APIに依存しているからです。
私たちはNext.jsからVite SPAへと移行しました。その理由は以下の通りです。
デバッグが容易になる サーバーエラーは、コンポーネントとの対応関係が分かりにくいことがあります。一方、クライアントサイドのエラーはブラウザ上で発生し、明確なスタックトレースが得られます。これにより、バグ修正が迅速化されます。
テストが容易になる 他のサーバーコンポーネントをレンダリングするサーバーコンポーネントを、簡単にユニットテストすることはできません。私たちはテスト可能性を維持するためだけに設計上の妥協を強いられました。それは間違いでした。
認証がシンプルになる SSRでは、リクエストのたびにサーバーがトークンを検証する必要があります。これは攻撃対象領域（アタックサーフェス）を増やし、クッキーのロジックを複雑にします。クライアントファーストのアプリであれば、認証はAPIという一箇所で処理できます。
インフラコストの削減 SSRは、すべてのリクエストに対して常に稼働しているサーバーを必要とします。一方、静的なフロントエンドはCDNからファイルとして配信されます。運用・セキュリティ対策が必要なサービスを一つ減らすことができます。
複雑さの軽減 Next.jsはサーバーとクライアントの分離を強制します。フロントエンドエンジニアは、ミドルウェアやキャッシュといったサーバー側の関心事まで管理しなければならず、それが開発の足かせとなりました。
私たちは段階的に移行を行いました。SEOが重要な公開ページにはNext.jsを残し、それ以外のすべてをVite SPAに移行しました。
トレードオフは軽微なものでした： • SEO：ログインが必要なダッシュボードにSEOは不要です。 • 初期ロード：データ集約型のアプリが遅い原因は、通常フレームワークではなくデータベースにあります。
SEOやSNSでのプレビューが重要な場合は、Next.jsを使用してください。 アプリがインタラクティブで、データ駆動型であり、ログイン後に使用されるものであれば、Vite SPAを使用してください。
「とりあえず」の選択をやめましょう。自分が実際に何を作ろうとしているのか、自問してみてください。
Source: https://dev.to/moruno21/you-dont-need-nextjs-heres-why-708