マルチゾーン
マルチゾーンは、ドメイン上の大規模なアプリケーションを、それぞれがパスセットを提供するより小さなNext.jsアプリケーションに分割するマイクロフロントエンドのアプローチです。これは、アプリケーション内の他のページとは無関係のページのコレクションがある場合に役立ちます。これらのページを別のゾーン(つまり、別のアプリケーション)に移動することにより、各アプリケーションのサイズを縮小し、ビルド時間を短縮し、ゾーンの1つにのみ必要なコードを削除できます。アプリケーションは分離されているため、マルチゾーンでは、ドメイン上の他のアプリケーションが独自のフレームワークを選択することもできます。
たとえば、分割したいページのセットが次のようにあるとします。
/blog/*
すべてのブログ投稿/dashboard/*
ユーザーがダッシュボードにログインしているときのすべてのページ/*
他のゾーンでカバーされていないWebサイトの残りの部分
マルチゾーンサポートを使用すると、すべて同じドメインで提供され、ユーザーには同じに見える3つのアプリケーションを作成できますが、各アプリケーションを個別に開発およびデプロイできます。


同じゾーン内のページ間を移動すると、ソフトナビゲーション(ページの再読み込みを必要としないナビゲーション)が実行されます。たとえば、この図では、 `/` から `/products` に移動すると、ソフトナビゲーションになります。
あるゾーンのページから別のゾーンのページ(たとえば、 `/` から `/dashboard`)に移動すると、ハードナビゲーションが実行され、現在のページのリソースがアンロードされ、新しいページのリソースが読み込まれます。頻繁に一緒にアクセスされるページは、ハードナビゲーションを回避するために同じゾーンに配置する必要があります。
ゾーンを定義する方法
ゾーンは、他のゾーンのページや静的ファイルとの競合を回避するためにassetPrefixも設定する通常のNext.jsアプリケーションです。
/** @type {import('next').NextConfig} */
const nextConfig = {
assetPrefix: '/blog-static',
}
JavaScriptやCSSなどのNext.jsアセットには、他のゾーンのアセットと競合しないように、 `assetPrefix` というプレフィックスが付けられます。これらのアセットは、各ゾーンの `/assetPrefix/_next/...` で提供されます。
別のより具体的なゾーンにルーティングされていないすべてのパスを処理するデフォルトアプリケーションには、 `assetPrefix` は必要ありません。
Next.js 15より前のバージョンでは、静的アセットを処理するために追加の書き換えが必要になる場合があります。これは、Next.js 15では不要になりました。
/** @type {import('next').NextConfig} */
const nextConfig = {
assetPrefix: '/blog-static',
async rewrites() {
return {
beforeFiles: [
{
source: '/blog-static/_next/:path+',
destination: '/_next/:path+',
},
],
}
},
}
リクエストを正しいゾーンにルーティングする方法
マルチゾーンのセットアップでは、パスは異なるアプリケーションによって処理されるため、パスを正しいゾーンにルーティングする必要があります。これを行うには、任意のHTTPプロキシを使用できますが、Next.jsアプリケーションの1つを使用して、ドメイン全体のリクエストをルーティングすることもできます。
Next.jsアプリケーションを使用して正しいゾーンにルーティングするには、 `rewrites` を使用できます。別のゾーンによって処理される各パスについて、そのパスを他のゾーンのドメインに送信する書き換えルールを追加します。例えば
async rewrites() {
return [
{
source: '/blog',
destination: `${process.env.BLOG_DOMAIN}/blog`,
},
{
source: '/blog/:path+',
destination: `${process.env.BLOG_DOMAIN}/blog/:path+`,
}
];
}
`destination` は、スキームとドメインを含む、ゾーンによって処理されるURLである必要があります。これは、ゾーンの本番ドメインを指している必要がありますが、ローカル開発でリクエストを `localhost` にルーティングするためにも使用できます。
**知っておくと良いこと**: URLパスはゾーンに対して一意である必要があります。たとえば、2つのゾーンが `/blog` を処理しようとすると、ルーティングの競合が発生します。
ミドルウェアを使用したリクエストのルーティング
rewrites
を通じてリクエストをルーティングすることが、リクエストのレイテンシオーバーヘッドを最小限に抑えるために推奨されますが、ルーティング時に動的な決定が必要な場合は、ミドルウェアを使用することもできます。たとえば、移行中など、パスをルーティングする場所を決定するために機能フラグを使用している場合は、ミドルウェアを使用できます。
export async function middleware(request) {
const { pathname, search } = req.nextUrl;
if (pathname === '/your-path' && myFeaturFlag.isEnabled()) {
return NextResponse.rewrite(`${rewriteDomain}${pathname}${search});
}
}
ゾーン間のリンク
異なるゾーンのパスへのリンクは、Next.js の <Link>
コンポーネントではなく、a
タグを使用する必要があります。これは、Next.js が <Link>
コンポーネント内の相対パスに対してプリフェッチとソフトナビゲーションを試みるため、ゾーンをまたいでは機能しないためです。
コードの共有
異なるゾーンを構成する Next.js アプリケーションは、任意のリポジトリに配置できます。ただし、これらのゾーンを モノレポ に配置して、コードをより簡単に共有することがよくあります。異なるリポジトリにあるゾーンの場合、パブリックまたはプライベートの NPM パッケージを使用してコードを共有することもできます。
異なるゾーンのページは異なる時間にリリースされる場合があるため、機能フラグは、異なるゾーン全体で機能を一斉に有効または無効にするのに役立ちます。
Vercel 上の Next.js アプリケーションの場合、モノレポ を使用して、影響を受けるすべてのゾーンを 1 つの git push
でデプロイできます。
サーバーアクション
マルチゾーンで サーバーアクション を使用する場合、ユーザー向けのドメインは複数のアプリケーションを提供する可能性があるため、ユーザー向けのオリジンを明示的に許可する必要があります。 next.config.js
ファイルに、次の行を追加します。
const nextConfig = {
experimental: {
serverActions: {
allowedOrigins: ['your-production-domain.com'],
},
},
}
詳細は、serverActions.allowedOrigins
を参照してください。
これは役に立ちましたか?