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

マイクロフロントエンドは、マイクロサービスの考え方をUIに適用したものです。大規模なアプリを、個別のチームが所有して独立して開発・デプロイできる単位に分割し、ユーザーには1つの体験として組み合わせます。

フロントエンドが1つの大きな構成だと、すべてのチームが1つのコードベースにコミットし、リリースを調整して、1つのビルドを共有する必要があります。組織が成長すると、これがボトルネックになり、ビルドの遅延、マージコンフリクト、リリース待ちの連鎖を引き起こします。

中核となる考え方はエンドツーエンドのオーナーシップです。チームはコードからデプロイまで、UIの担当範囲を所有します。専用のリポジトリ、パイプライン、ランタイムを持つため、他のチームを待たずに開発を進められます。

チームは技術レイヤーではなく、ビジネス機能（Checkout、Search、Profile）ごとに分割します。各スライスには、その機能に必要なUI、ロジック、データアクセスが含まれます。

各マイクロフロントエンドは、それぞれのスケジュールでリリースされます。SearchチームはCheckoutに手を加えず、1日に10回デプロイできます。リリースが分離されるため、リスクと調整作業を減らせます。

チームはスライスごとに異なるフレームワークを選択できます。実際には、共有ツールを使うために、多くの組織が標準化しています（例：すべてVue）。ただし、合理的な理由がある場合は、アーキテクチャとして多様性も認められます。

スライスを組み合わせる方法の1つが、ビルド時の統合です。各マイクロフロントエンドをパッケージとして公開し、コンテナアプリが依存関係としてインストールして、まとめてビルドします。

ビルド時統合はシンプルですが、リリースが密結合になります。新しいCheckoutのバージョンをリリースするには、コンテナを再ビルドして再デプロイしなければなりません。真の独立デプロイは失われます。

ランタイム統合では、ブラウザ上で実行時にマイクロフロントエンドを読み込みます。コンテナは必要になった時点でリモートのコードを取得します。各リモートは独立してデプロイでき、コンテナは再ビルドなしで最新の内容を取得します。

代表的なランタイム技術がModule Federationです。これは、あるアプリがモジュールを公開し、別のアプリが実行時にネットワーク経由で利用できるようにするビルド機能です。共通の依存関係を共有することもできます。今後のレッスンで使用します。

シンプルさと単一のデプロイを重視する小規模チームには、ビルド時を使用します。独立したデプロイとチームの自律性を優先し、運用の複雑さが増すことを受け入れられる場合は、ランタイム（Module Federation）を使用します。

マイクロフロントエンドの原則について、理解度を確認しましょう。

マイクロフロントエンドの原則を学びました：

• 大規模なUIを、独立して所有・デプロイできるスライスに分割し、ユーザー向けに組み合わせます。
• チームの自律性：ビジネス機能の垂直スライスを、エンドツーエンドで所有します。
• 独立したデプロイ：各スライスをそれぞれのスケジュールでリリースします。
• 技術の多様性は任意であり、多くのチームは標準化します。
• 統合には、ビルド時（シンプルだがリリースが密結合）とランタイム（Module Federationによる真の独立性）があります。