Micro-Frontendの概念とトレードオフ

マイクロフロントエンドは、マイクロサービスの考え方をUI層に拡張したものです。1つのWebアプリケーションを、別々のチームがそれぞれ所有、開発、デプロイする、独立したフロントエンドの単位に分割します。

主な統合戦略は3つあります。ビルド時（npmパッケージ）、サーバーサイド（エッジでの合成）、実行時（Module Federation、iframe、Web Components）です。

共有コンポーネントをnpmパッケージとして公開します。シンプルですが、変更のたびにすべての利用側を再リリース、再デプロイする必要があり、真に独立したデプロイとはいえません。

Webpack 5のModule Federationを使うと、1つのアプリ（ホスト）が別のアプリ（リモート）から実行時にコンポーネントを読み込めます。これにより、真に独立したデプロイが可能になります。

最大限の分離を実現するには、マイクロフロントエンドをiframeに埋め込みます。利点はCSS/JSの競合がゼロになることです。欠点は、スクロール、フォーカス、サイズ調整などのUXが悪いこと、状態の共有が難しいこと、SEOに不向きなことです。

各マイクロフロントエンドをカスタム要素でラップします。どのフレームワークでも動作し、ネイティブな分離を提供しますが、コンテキスト共有などのReact固有の機能は利用できません。

独立したデプロイ（他チームに影響を与えずに、1チームのUIだけをデプロイできます）、チームの自律性（各チームが独自の技術スタックと依存関係を選べます）、スケーラビリティ（コードの競合なしにチームが並行して作業できます）があります。

運用の複雑さ（リポジトリ、CIパイプライン、デプロイの増加）、バンドルの重複（共有しないとReactが複数回読み込まれます）、パフォーマンスへのオーバーヘッド、境界をまたぐデバッグの難しさが生じます。

マイクロフロントエンドは、同じプロダクトに複数の大規模チームが取り組む場合、セクションごとに異なる技術スタックが必要な場合、または各セクションを完全に独立してデプロイする必要がある場合に、特に効果を発揮します。

小規模なチーム（オーバーヘッドが利点を上回ります）、単純なアプリケーション、またはフロントエンド全体を完全に管理できる場合は避けてください。その場合は、Nx/Turborepoを使ったモノレポで通常は十分です。

統合戦略にかかわらず、共有デザインシステム（パッケージとして公開するか、Module Federation経由で公開します）によって、マイクロフロントエンド間の見た目の一貫性を保てます。

実行時にマイクロフロントエンドを真に独立してデプロイできる統合方式はどれですか？

マイクロフロントエンドは、チームの自律性と独立したデプロイを実現するためにUIを分割します。統合方法には、npmパッケージ（シンプルですが独立していません）からModule Federation（実行時に統合され、真に独立しています）までがあります。運用コストを考慮してください。マイクロフロントエンドは大規模で複数チームが関わるプロダクトに適していますが、小規模なプロジェクトには複雑さが加わります。