Module Federationの基礎

Module Federationを使うと、JavaScriptアプリケーションは、別の独立してデプロイされたアプリケーションから実行時にコードを読み込み、実行できます。Webpack 5で始まったこのパターンは、現在ではネイティブのImport mapと動的importでも実現できます。

大規模な組織では、モノリスを複数の「マイクロフロントエンド」に分割し、それぞれを独立してデプロイします。シェルホストと複数の機能アプリケーションで構成されます。Module Federationを使うと、シェルはビルド時にまとめてバンドルすることなく、各機能を必要なときに読み込めます。

Webpack 5では、ホストが利用する他のアプリをremotesとして宣言し、リモート側は提供するものをexposesとして宣言します。ランタイムは起動時に各リモートから小さなマニフェストを取得し、ホストがimportした時点でチャンクをダウンロードします。

Webpackを使わなくても、リモートのESMバンドルを指すImport mapと、読み込みに使う動的importで同じ考え方を実現できます。ホストのImport mapで"feature-cart": "https://cart-team.example.com/entry.js"と指定すると、import("feature-cart")で最新のデプロイ済みバージョンが読み込まれます。

調整せずに実装すると、各リモートがReactのコピーを独自に配布することになります。Federationツールでは共有依存関係を宣言でき、最初にReactを読み込んだリモートが、それを他のすべてのリモートで利用できるようにします。ネイティブなアプローチでは、すべてのリモートが同じReact URLを指すようにImport mapを使用します。

各チームが自分のリモートを所有し、任意のタイミングでデプロイします。ホストを再ビルドする必要はなく、次回のページ読み込み時（またはキャッシュバスティングによって）新しいバージョンを取得します。これにより、リリースサイクルを完全に分離できます。

リモートをバージョン付きURL（/v1/entry.js、/v2/entry.js）に固定すると、ホストのアップグレードを暗黙的ではなく意図的に実行できます。JSPMなどのツールを使い、Import mapレベルでsemverの照合を行うチームもあります。

Federationには、実行時の複雑さが加わります。ネットワークリクエストの増加、オリジンをまたぐデバッグの難しさ、共有依存関係に互換性がないリスクなどです。本当に独立したデプロイが必要な場合に使用してください。小規模なプロジェクトでは、単一のビルドのほうがシンプルで高速です。

1つのリモートがクラッシュしても、ホスト全体が停止してはいけません。動的インポートをエラーバウンダリ（React）またはtry/catch（vanilla）でラップし、リモートが失敗したときはフォールバックUIを表示します。機能が一時的に壊れていても、シェルは機能し続けます。

リモートのエクスポートには、ホスト側から利用できるコンパイル時の型情報がありません。両方の側から利用する共有TypeScript型を別パッケージで生成するか、フェデレーションの境界で実行時検証（Zod、io-ts）を使用します。

ネイティブフェデレーション（import maps + ESM）はシンプルで標準ベースですが、Webpackの共有依存関係の調整機能はありません。共有依存関係が多い複雑なアプリにはWebpack/Module Federationを、よりシンプルなマイクロフロントエンド構成にはネイティブフェデレーションを選択します。

W3Cでは、ネイティブフェデレーションの機能を高める、より高度なモジュール読み込みプリミティブが検討されています。これには、共有依存関係のネゴシエーションの改善も含まれます。現時点では、import mapsを基盤として扱い、その上にフェデレーションのツールを構築してください。

大規模なアプリケーションでModule Federationを使用する主な動機は何ですか。

Module Federationを使うと、ホストは独立してデプロイされたリモートから実行時にコードを読み込めます。Webpack 5のツールは共有依存関係のネゴシエーションを追加し、ネイティブフェデレーションはimport mapsと動的インポートを使用します。複数のチームで構成するマイクロフロントエンドアーキテクチャで利用し、独立してデプロイできる自由と引き換えに、複雑さが増すことを受け入れてください。