コンテンツにスキップ
Pages Routerガイドマルチゾーン

マルチゾーンとNext.jsを使用したマイクロフロントエンドの構築方法

例

マルチゾーンは、ドメイン上の大規模なアプリケーションを、それぞれパスのセットを提供する小規模なNext.jsアプリケーションに分離するマイクロフロントエンドのアプローチです。これは、アプリケーション内の他のページとは無関係なページのコレクションがある場合に役立ちます。これらのページを別のゾーン（つまり、別のアプリケーション）に移動することで、各アプリケーションのサイズを削減し、ビルド時間を短縮し、一方のゾーンにのみ必要なコードを削除できます。アプリケーションは分離されているため、マルチゾーンでは、ドメイン上の他のアプリケーションが独自のフレームワークを選択することもできます。

たとえば、以下のようなページのセットを分割したいとします。

  • すべてのブログ投稿の/blog/*
  • ユーザーがダッシュボードにログインしている場合、すべてのページの/dashboard/*
  • 他のゾーンでカバーされていないウェブサイトの残りの部分の/*

マルチゾーンサポートを使用すると、すべて同じドメインで提供され、ユーザーからは同じように見える3つのアプリケーションを作成できますが、各アプリケーションを独立して開発およびデプロイできます。

Three zones: A, B, C. Showing a hard navigation between routes from different zones, and soft navigations between routes within the same zone.

同じゾーン内のページ間をナビゲートすると、ソフトナビゲーション（ページをリロードせずに実行されるナビゲーション）が行われます。たとえば、この図では、/から/productsへのナビゲーションはソフトナビゲーションになります。

1つのゾーンのページから別のゾーンのページへのナビゲーション（たとえば、/から/dashboard）は、ハードナビゲーションを実行し、現在のページのすべてのリソースをアンロードして新しいページのすべてのリソースをロードします。頻繁に一緒にアクセスされるページは、ハードナビゲーションを回避するために同じゾーンに配置する必要があります。

ゾーンの定義方法

ゾーンは通常のNext.jsアプリケーションであり、他のゾーンのページや静的ファイルとの競合を回避するためにassetPrefixも構成します。

next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  assetPrefix: '/blog-static',
}

JavaScriptやCSSなどのNext.jsアセットにはassetPrefixが付加されるため、他のゾーンのアセットと競合しないようになります。これらのアセットは、各ゾーンで/assetPrefix/_next/...の下に提供されます。

他のより具体的なゾーンにルーティングされないすべてのパスを処理するデフォルトのアプリケーションでは、assetPrefixは必要ありません。

Next.js 15より前のバージョンでは、静的アセットを処理するために追加の書き換えが必要な場合もあります。これはNext.js 15では不要になりました。

next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  assetPrefix: '/blog-static',
  async rewrites() {
    return {
      beforeFiles: [
        {
          source: '/blog-static/_next/:path+',
          destination: '/_next/:path+',
        },
      ],
    }
  },
}

リクエストを正しいゾーンにルーティングする方法

マルチゾーンの設定では、パスは異なるアプリケーションによって提供されるため、正しいゾーンにルーティングする必要があります。これには任意のHTTPプロキシを使用できますが、ドメイン全体の要求をルーティングするためにNext.jsアプリケーションのいずれかを使用することもできます。

Next.jsアプリケーションを使用して正しいゾーンにルーティングするには、rewritesを使用できます。別のゾーンによって提供される各パスについて、そのパスを他のゾーンのドメインに送信する書き換えルールを追加します。また、静的アセットの要求も書き換える必要があります。たとえば

next.config.js
async rewrites() {
    return [
        {
            source: '/blog',
            destination: `${process.env.BLOG_DOMAIN}/blog`,
        },
        {
            source: '/blog/:path+',
            destination: `${process.env.BLOG_DOMAIN}/blog/:path+`,
        },
        {
            source: '/blog-static/:path+',
            destination: `${process.env.BLOG_DOMAIN}/blog-static/:path+`,
        }
    ];
}

destinationは、ゾーンによって提供されるURL（スキームとドメインを含む）である必要があります。これはゾーンの本番ドメインを指している必要がありますが、ローカル開発でlocalhostに要求をルーティングするためにも使用できます。

知っておくと良いこと：URLパスはゾーンごとに一意である必要があります。たとえば、2つのゾーンが/blogを提供しようとすると、ルーティングの競合が発生します。

プロキシを使用したリクエストのルーティング

要求のレイテンシオーバーヘッドを最小限に抑えるために、rewritesを介した要求のルーティングが推奨されますが、ルーティング時に動的な決定が必要な場合はプロキシも使用できます。たとえば、機能フラグを使用してパスをどこにルーティングするかを決定する場合（移行中など）、プロキシを使用できます。

proxy.js
export async function proxy(request) {
  const { pathname, search } = req.nextUrl;
  if (pathname === '/your-path' && myFeatureFlag.isEnabled()) {
    return NextResponse.rewrite(`${rewriteDomain}${pathname}${search});
  }
}

ゾーン間のリンク

別のゾーンのパスへのリンクは、Next.jsの<Link>コンポーネントではなく、aタグを使用する必要があります。これは、Next.jsが<Link>コンポーネント内の相対パスをプリフェッチしてソフトナビゲートしようとするため、ゾーンをまたいで機能しないためです。

コードの共有

異なるゾーンを構成するNext.jsアプリケーションは、任意のリポジトリに配置できます。しかし、コードを簡単に共有するために、これらのゾーンをモノレポに配置すると便利であることがよくあります。異なるリポジトリにあるゾーンの場合、公開またはプライベートNPMパッケージを使用してコードを共有することもできます。

異なるゾーンのページは異なる時期にリリースされる可能性があるため、フィーチャーフラグは、異なるゾーン全体で機能を同期して有効または無効にするのに役立ちます。