「全部 Next.js」でも「全部 Django」でもなく、
画面の性質ごとに分ける構成を採るケースが増えました。実際の線引きです。
線引きの実例
| 画面 | 担当 | 理由 |
|---|---|---|
| LP・記事・お問い合わせ | Django（テンプレート） | 更新が少ない。ビルド不要で直せる |
| 会員向けの動的画面 | Next.js | 状態が複雑。操作が多い |
| 管理画面 | Django admin ベース | 作り込むより既存を活かす |
判断の軸は 「誰がどのくらいの頻度で直すか」 です。
文言修正が多いページをビルド必須にすると、運用が確実に詰まります。
URL の振り分け
同一ドメインで、リバースプロキシがパスで振り分けます。
location /app/ { proxy_pass http://nextjs; } # 会員向け
location / { proxy_pass http://django; } # それ以外
同一ドメインなので CORS の設定が要らず、Cookie もそのまま共有できます。
この一点だけで、認証まわりの設計が大幅に単純になります。
認証の共有
Django のセッション Cookie を Next.js 側からも使います。
Next.js のサーバー側で Django に問い合わせて、ログイン状態を確認します。
// サーバーサイドで実行（Cookie をそのまま転送する）
const res = await fetch(`${API}/api/me/`, {
headers: { cookie: req.headers.cookie ?? "" },
});
if (res.status === 401) return { redirect: { destination: "/login" } };
トークンを新たに発行しないのが要点です。
発行すると失効管理を二重に持つことになり、事故の温床になります。
運用して分かった注意点
1. 静的ファイルのパスが衝突する
両方が /static/ を使おうとして事故ります。
Next.js 側は assetPrefix を分けておきます。
2. エラーページが2種類になる
404 のデザインが Django と Next.js で違うと、体験がちぐはぐになります。
どちらかに寄せるか、同じHTMLを共有する必要があります。
3. デプロイ順序
API を先に更新すると、古いフロントが壊れることがあります。
後方互換を保ったままAPIを出し、フロントを後からという順序に固定します。
4. ログが分断される
前段の Nginx で相関IDを発行し、両方に渡すようにしました。
proxy_set_header X-Request-ID $request_id;
この構成が向かないケース
- チームが1人で、画面数も少ない → Django だけで十分
- 全画面が高度に動的 → 全部 Next.js のほうが単純
中途半端な規模でこそ効く構成です。
まとめ
- 「誰がどの頻度で直すか」で担当を決める
- 同一ドメインにして CORS と二重認証を避ける
- 静的パス・エラーページ・デプロイ順序・ログの4点が実運用の落とし穴