マイクロフロントエンドアーキテクチャ

マイクロフロントエンドは、マイクロサービスの考え方をUIに広げたものです。大規模なWebアプリを、個別に開発、テスト、デプロイできる複数の部分に分割します。それぞれの部分を別のチームが担当し、実行時に1つの体験として組み合わせます。

単一の巨大なAngularアプリ（「モノリスフロントエンド」）では、すべてのチームが1つのリリース計画、1つのビルド、1つのデプロイに依存します。チームが大きくなるほど、開発全体が遅くなります。マイクロフロントエンドを使えば、各チームが独自のスケジュールでリリースできます。

中核となる特性は独立デプロイ性です。チェックアウトチームは、商品カタログを再ビルドまたは再デプロイすることなく、新しいチェックアウトフローをデプロイできます。各リモートは、独自のパイプラインで管理される別個の成果物です。

アーキテクチャ上は、1つ以上のリモートを読み込むホスト（シェル）が存在します。シェルは最上位のルーティングとレイアウトを担当し、リモートは必要に応じて読み込まれる機能領域を提供します。

リモートは、ビルド時、サーバー上（SSI/エッジ）、またはブラウザーの実行時に組み合わせることができます。Module Federationによる実行時構成は、独立したデプロイを維持できるため、Angularでは最も一般的です。

Module Federationを使うと、ビルド済みのアプリがモジュールを公開し、別のビルド済みアプリが実行時にHTTP経由で読み込めます。共通ライブラリを共有するため、重複して含める必要もありません。これは、Angularの多くのマイクロフロントエンドを支える仕組みです。

各マイクロフロントエンドは、明確なビジネスドメイン（カタログ、チェックアウト、アカウントなど）に対応させる必要があります。明確なドメイン境界によってチーム間の結合を最小限に抑えることが、この仕組みの目的です。認証やデザインシステムなどの共通事項は、明示的な契約になります。

マイクロフロントエンドには、リモート間のバージョンのずれ、設定ミスによる依存関係の重複、境界をまたぐデバッグの難しさ、実行時の読み込み失敗など、現実的な複雑さが加わります。チーム規模によってそのオーバーヘッドが正当化される場合にのみ導入してください。

小規模なチームや単一のプロダクトでは、遅延ロードするルートを備えた、適切に構成されたモノリスの方がシンプルで高速です。マイクロフロントエンドの効果が発揮されるのは、複数のチームが同じアプリに対して独立してデプロイする必要がある場合です。

フランケンシュタインのようなUIを避けるため、チーム間でデザインシステムのライブラリとグローバルスタイルを共有します。各リモートは別々にビルドされるため、一貫性は偶然ではなく、意図的な契約として保つものです。

Angularのリモートでは、実行時にAngularフレームワークのコピーを1つだけ共有する必要があります。2つのAngularバージョンを読み込むと、依存性注入が壊れ、バンドルも肥大化します。Native Federationなどのツールが、この共有を管理してくれます。

マイクロフロントエンドの最大の利点は何ですか？

マイクロフロントエンドでは、大規模なアプリを、ホストシェルが読み込む独立デプロイ可能なリモートに分割し、それぞれをビジネスドメインに対応させます。Module Federationによる実行時構成がAngularの標準であり、Angularフレームワークのコピーは1つだけ共有する必要があります。チーム規模による結合の問題を解決する一方で、運用上のコストも増加します。