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

サンプル

With Zones

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

例えば、以下のような分割したいページのセットがあるとします：

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

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

3つのゾーン：A、B、C。異なるゾーンのルート間のハードナビゲーションと、同じゾーン内のルート間のソフトナビゲーションを示しています。

同じゾーン内のページ間を移動する場合は、ページの再読み込みを必要としないソフトナビゲーションが実行されます。例えば、このダイアグラムでは、/から/productsへの移動はソフトナビゲーションになります。

あるゾーンのページから別のゾーンのページ（例えば、/から/dashboard）への移動では、ハードナビゲーションが実行され、現在のページのリソースがアンロードされ、新しいページのリソースがロードされます。頻繁に一緒に訪問されるページは、ハードナビゲーションを避けるために同じゾーンに配置すべきです。

ゾーンの定義方法

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

next.config.js

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

Next.jsのアセット（JavaScriptやCSSなど）には、他のゾーンのアセットと競合しないように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アプリケーションの1つを使用してドメイン全体のリクエストをルーティングすることもできます。

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+`,
        }
    ];
}

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

補足: URLパスはゾーンごとに一意である必要があります。例えば、2つのゾーンが/blogを提供しようとすると、ルーティングの競合が発生します。

ミドルウェアを使用したリクエストのルーティング

リクエストをrewritesを通じてルーティングすることは、リクエストのレイテンシーオーバーヘッドを最小限に抑えるために推奨されますが、ルーティング時に動的な判断が必要な場合はミドルウェアも使用できます。例えば、移行中などにパスをどこにルーティングするかを決めるためにフィーチャーフラグを使用している場合、ミドルウェアを使用できます。

middleware.js

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

const nextConfig = {
  experimental: {
    serverActions: {
      allowedOrigins: ['your-production-domain.com'],
    },
  },
}

詳細についてはserverActions.allowedOriginsを参照してください。

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

ゾーンの定義方法

リクエストを適切なゾーンにルーティングする方法

ミドルウェアを使用したリクエストのルーティング

ゾーン間のリンク

コードの共有

Server Actions