Module Federation: マイクロフロントエンドにおけるランタイムモジュール共有の決定版ガイド

絶えず進化するWeb開発の世界において、私たちは重大なアーキテクチャの転換を目の当たりにしてきました。私たちは、スケーラビリティとチームの自律性を求め、モノリシックアーキテクチャからバックエンドのマイクロサービスへと旅をしてきました。今、同じ革命がフロントエンドを変革しています。マイクロフロントエンドの時代が到来し、その中心には、それをすべて実用的なものにする強力なテクノロジーがあります。それがModule Federationです。

マイクロフロントエンドの中心的な課題は、常に述べるのは簡単でも解決するのは困難でした。それは、複数の独立してデプロイされたアプリケーションから、単一でまとまりのあるユーザーエクスペリエンスを、遅く、肥大化し、管理不能な混乱を生じさせることなく、どのように構築するかということです。コンポーネントライブラリやReactのようなフレームワークといった共通のコードを、バージョニングの悪夢や協調リリースを強制することなく、どのように共有すればよいのでしょうか？

これこそが、Module Federationがエレガントに解決する問題です。Webpack 5で導入されたこの機能は、単なる新機能ではなく、私たちがWebアプリケーションの構築とデプロイについて考える方法におけるパラダイムシフトです。この包括的なガイドでは、Module Federationの「何か」「なぜ」「どのように」を探り、その最も変革的な能力であるランタイムモジュール共有に焦点を当てます。

簡単な復習：マイクロフロントエンドとは？

Module Federationのメカニズムに飛び込む前に、マイクロフロントエンドが何を意味するのかについて認識を合わせましょう。大規模なeコマースサイトを想像してみてください。モノリシックな世界では、フロントエンド全体（商品検索、商品詳細、ショッピングカート、チェックアウト）が単一の巨大なアプリケーションです。チェックアウトボタンへの変更が、アプリケーション全体のテストと再デプロイを必要とするかもしれません。

マイクロフロントエンドアーキテクチャは、このモノリスをビジネスドメインに沿って分割します。例えば、次のようなチームが存在するかもしれません。

• 検索バーと結果ページを所有する検索チーム
• 商品詳細と推奨商品を所有する商品チーム
• ショッピングカートと支払いプロセスを所有するチェックアウトチーム

各チームは、アプリケーションの自身の担当部分を独立して構築、テスト、デプロイできます。これにより、いくつかの主要な利点がもたらされます。

• 自律的なチーム： チームは独自のスケジュールで作業しリリースできるため、開発が加速します。
• 独立したデプロイ： 推奨エンジン内のバグが、支払いフローへの重要な更新を妨げることはありません。
• 技術の柔軟性： 検索チームがVue.jsを使用し、商品チームがReactを使用するなど、チームは特定のドメインに最適なツールを選択できます（ただし、これには慎重な管理が必要です）。

しかし、このアプローチは共有と一貫性に関する独自の課題をもたらし、それが私たちを古いやり方に引き戻します。

従来のコード共有方法（そして、なぜそれらが不十分なのか）

歴史的に、チームは異なるフロントエンドアプリケーション間でコードを共有するためにいくつかの方法を試してきましたが、それぞれにマイクロフロントエンドの文脈では重大な欠点がありました。

NPMパッケージ

最も一般的なアプローチは、共有コンポーネントやユーティリティをバージョン管理されたNPMパッケージとして公開することです。共有コンポーネントライブラリが典型的な例です。

• 問題点： これはビルド時の依存関係です。チームAが共有の`Button`コンポーネントを`my-ui-library`でバージョン1.1から1.2に更新しても、チームBとチームCは、手動で`package.json`を更新し、`npm install`を実行し、マイクロフロントエンド全体を再デプロイするまで、その更新を取得できません。これは密結合を生み出し、独立したデプロイの目的を損ないます。また、同じコンポーネントの複数のバージョンがブラウザにロードされることになり、最終的なバンドルが肥大化します。

共有ワークスペースを持つモノレポ

モノレポ（LernaやYarn/NPMワークスペースなどのツールを使用）は、すべてのマイクロフロントエンドを単一のリポジトリに保持します。これにより、共有パッケージの管理が簡素化されます。

• 問題点： モノレポは開発者体験の向上には役立ちますが、中心的なランタイムの問題は解決しません。依然としてビルド時の依存関係に依存しています。共有ライブラリへの変更は、変更を反映するために、それを消費するすべてのアプリケーションを再ビルドおよび再デプロイする必要があります。

`