App Router は『デフォルトでサーバー寄り』が前提
Next.js の App Router は Pages Router と思想が大きく異なります。本記事では編集部の視点で、実務で押さえるべきポイントを公開情報をもとに整理します。バージョンによって挙動は変わるため最新は公式ドキュメントをご確認ください。React 学習ロードマップ もご参考に。
Server Components の基本
(1) デフォルトでServer：use client が必要なときだけ Client。(2) fetch はそのまま使える：Server側で実行・キャッシュも有効。(3) Client境界の意識：イベントハンドラ/状態は Client。(4) props はシリアライズ可能：関数や Date 等の扱いに注意。(5) RSC payload：HTML と差分配信の仕組みを理解。
Route Handlers と Server Actions
(1) app/api/route.ts：HTTP メソッドごとに export。(2) Server Actions：form 送信を関数呼び出しのように記述。(3) revalidatePath/Tag：書き込み後のキャッシュ無効化。(4) 外部APIとの境界：認証ヘッダ付与はServer側で。(5) RPC 的な使い方：tRPC や Hono との併用も選択肢。REST API設計 も参考に。
キャッシュ戦略の4層
(1) Request Memoization：同一レンダ内の重複fetch排除。(2) Data Cache：fetch 結果の永続化(revalidate指定)。(3) Full Route Cache：静的ページのHTML/RSCをキャッシュ。(4) Router Cache：クライアント側の遷移キャッシュ。(5) dynamic = "force-dynamic"：明示的に動的にする。バージョンで挙動が変わる領域なので最新公式情報をご確認ください。
SEO と Metadata
(1) metadata export：title / description を関数で動的生成。(2) generateMetadata：fetch 結果から動的に。(3) OGP/Twitter Card：openGraph/twitter フィールドで設定。(4) sitemap.ts/robots.ts：型安全に生成。(5) canonical URL：重複対策を必ず設定。
本番運用の注意点
(1) middleware の負荷：全リクエストで実行されるため軽量に。(2) cookies/headers の使用：Server側の挙動を理解。(3) 並行fetch でレイテンシ短縮：Promise.all を活用。(4) エラーハンドリング：error.tsx / not-found.tsx を配置。(5) セルフホスト vs Vercel：機能差と運用負荷を理解。
失敗しがちなパターン
(1) 全部 use client：Server Components の恩恵を捨てる。(2) キャッシュ意図せず固定化：書き込み後の revalidate 忘れ。(3) Server Action で大きな返り値：シリアライズコスト。(4) Edge Runtime の制約に気付かない。(5) middleware で重い処理。対策は、(1)Client境界の最小化、(2)revalidate 必須、(3)返り値最小化、(4)使用ライブラリ確認、(5)middleware は判定のみ、です。