マイクロフロントエンド

Micro-Frontendsとは?

Micro-Frontendsは、単一のWebアプリケーションを、独立して開発、テスト、デプロイされる小さなフロントエンドアプリケーションに分解するアーキテクチャスタイルです。各アプリケーションは別々のチームが所有し、それらを組み合わせてシームレスなユーザー体験を創出します。このアプローチは、マイクロサービスのパラダイムをフロントエンドに拡張し、Webアプリケーション開発に自律性、スケーラビリティ、技術的柔軟性をもたらします。

各Micro-Frontendは異なるフレームワークで構築でき、異なるスケジュールでデプロイでき、異なる組織単位で保守できます。これにより、チームは独立して作業しながら、統一されたアプリケーションに貢献できます。このアーキテクチャは、アプリケーションの複雑さが増し、チームサイズが拡大する際のフロントエンド開発のスケーリングという課題に対処します。

歴史的背景

Webアプリケーションの複雑さが増すにつれ、フロントエンドのコードベースは大規模なモノリスへと進化し、スケーリングと保守が困難になりました。マイクロサービスが独立したサービスを通じてバックエンド開発に革命をもたらした一方で、フロントエンド開発は依然として密結合でモノリシックなままでした。

「Micro-Frontends」という用語は、2016年にThoughtWorks Technology Radarで紹介され、その後Martin Fowlerによって広められました。このアプローチは、新しいフレームワークの統合の難しさ、大規模チームでの並行開発の課題、レガシーUIの近代化における高いリスクといった課題から生まれました。

Single-Page Applicationsが標準となるにつれ、フロントエンドのモジュール化の必要性が高まり、チームのスケーラビリティと技術スタックの柔軟性を可能にするMicro-Frontendパターンの採用につながりました。

中核原則

ドメインベースの分解

Micro-Frontendsは通常、機能やビジネスドメイン(「検索」「カート」「プロフィール」など)の垂直的なスライスを表します。各々は、特定のビジネス機能に責任を持つクロスファンクショナルチームによってエンドツーエンドで開発されます。

チームの自律性

各Micro-Frontendチームは、開発、テスト、デプロイ、保守という完全なソフトウェア開発ライフサイクルを所有します。この自律性により、デリバリーが加速し、ボトルネックが減少し、チームは自分のドメインに適した技術的決定を行えます。

独立した技術選択

チームは、Micro-Frontendごとに異なるフレームワーク、ライブラリ、さらにはプログラミング言語を選択できます。あるチームはReactを使用し、別のチームはVue.js、さらに別のチームはAngularを使用できます。各々が特定の要件に最適化されています。

疎結合

Micro-Frontendsは、明確に定義されたAPIとブラウザイベントを通じて通信し、共有グローバル状態を避けます。これにより、偶発的な依存関係が減少し、統合が簡素化され、コンポーネントの独立した進化が可能になります。

ランタイム合成

個々のMicro-Frontendsは、ランタイムで全体のアプリケーションに合成され、シームレスなユーザー体験を創出します。合成は、サーバーサイドアセンブリ、クライアントサイド統合、またはハイブリッドアプローチを通じて行われます。

主な利点

段階的な近代化: 「strangler figパターン」を可能にし、レガシーセクションを新しいMicro-Frontendsで段階的に置き換えることで、ビッグバン書き換えと比較して移行リスクを軽減します。

シンプルなコードベース: 各Micro-Frontendは小さく、より焦点が絞られており、開発者の認知負荷とエラー率を削減します。理解、テスト、保守が容易になります。

独立したデプロイ: チームはMicro-Frontendsを独立してデプロイでき、リリースサイクルの高速化と調整オーバーヘッドの削減を実現します。修正や機能追加にグローバルな再デプロイは不要です。

チームのスケーラビリティ: 複数のチームが並行して機能を開発・出荷でき、デリバリーを加速し、開発能力をスケールします。複雑な製品を持つ大規模組織にとって不可欠です。

技術的柔軟性: チームはアプリケーション全体に影響を与えることなく、新しいフレームワークや言語を試すことができます。新興技術を段階的に採用しやすくなります。

回復力の向上: 1つのMicro-Frontendの障害は隔離され、ユーザーへの影響を最小限に抑えます。遅延ロードにより、ルートごとに必要なコンポーネントのみを配信し、初期ロードパフォーマンスが向上します。

課題とトレードオフ

運用の複雑さ: 複数のデプロイパイプライン、バージョン管理、監視の管理はオーバーヘッドを生じます。チーム間の変更調整が複雑になる可能性があります。

バンドルサイズの懸念: 異なるライブラリバージョンにより、依存関係の重複によってバンドルサイズが増加し、ロード時間が遅くなる可能性があります。慎重な依存関係管理が必要です。

ガバナンスのバランス: 技術的自由度が高すぎると「フレームワーク無秩序」につながり、一貫したユーザー体験が困難になり、保守コストが増加します。過度な制約なしにガバナンスが必要です。

CSSと名前空間管理: 分離(CSSモジュール、Shadow DOM、厳格な規約)がないと、スタイルやグローバル変数がMicro-Frontends間で漏れ、バグや視覚的不整合を引き起こします。

通信の複雑さ: Micro-Frontends間の堅牢で疎結合な通信メカニズムの定義は容易ではなく、特に調整を必要とする複雑なワークフローでは困難です。

テスト要件: 独立してデプロイされた部品から組み立てられるアプリケーションのエンドツーエンド品質を確保するには、効果的な統合テストと回帰テスト戦略が必要です。

統合パターン

サーバーサイドテンプレート合成

サーバーが各Micro-Frontendから提供されるフラグメントから最終的なHTMLページを組み立てます。

利点: 強力な分離、ユニバーサルレンダリング、最小限のクライアントサイドJavaScript。

欠点: 限定的なインタラクティビティ、粗い更新、動的UIには遅い。

例: Nginx SSI (Server Side Includes)。

ビルドタイム統合

Micro-Frontendsをライブラリ(npmパッケージ)として公開し、ビルド時にコンテナアプリケーションがインポートします。

利点: 重複排除された依存関係、最適化されたバンドル。

欠点: 独立したデプロイを失い、調整されたリリースが必要。

ランタイム統合

Iframes: 各Micro-Frontendがiframe内にロードされ、コンテナが可視性を管理します。

• 長所: 最大限の分離、セキュリティ
• 短所: 不器用なナビゲーション、貧弱な通信、パフォーマンスオーバーヘッド

JavaScriptエントリポイント: 各Micro-Frontendがコンテナによって呼び出されるグローバルレンダー関数を公開します。

• 長所: 柔軟性、独立したデプロイ
• 短所: 名前空間の衝突、依存関係管理の課題

Web Components: Shadow DOMを活用したカプセル化によりカスタムHTML要素として配布されます。

• 長所: 強力なカプセル化、技術スタック非依存、ネイティブブラウザサポート
• 短所: 高度な通信の複雑さ

Module Federation (Webpack 5+): 個別にビルドされたアプリケーション間でのコードのランタイムロードと共有。

• 長所: 動的ロード、きめ細かい共有
• 短所: 慎重な設定と運用規律が必要

実装例

フードデリバリーアプリケーションアーキテクチャ

ドメイン分解:

• レストラン閲覧: 検索とフィルタリング機能
• 注文ページ: メニュー選択、カスタマイズ、チェックアウト
• ユーザープロフィール: アカウント設定、注文履歴

チーム構造: 各ページは専任チームが所有するMicro-Frontendです。

統合: コンテナアプリがグローバルレイアウト、ナビゲーション、共有サービスを提供します。Micro-Frontendsはユーザーがナビゲートする際に動的にロードされます。

Web Components実装:

class BrowseRestaurants extends HTMLElement {
  connectedCallback() {
    this.innerHTML = '<div>Restaurant browsing interface</div>';
  }
}
window.customElements.define('browse-restaurants', BrowseRestaurants);

class OrderFood extends HTMLElement {
  connectedCallback() {
    this.innerHTML = '<div>Order management interface</div>';
  }
}
window.customElements.define('order-food', OrderFood);

コンテナ合成:

<div id="main">
  <browse-restaurants></browse-restaurants>
  <!-- ルーティングに基づいてコンポーネントを動的に切り替え -->
</div>

通信: ブラウザネイティブのCustomEvent、ローカルストレージ、またはイベントバスを使用して、疎結合を維持しながらMicro-Frontends間のインタラクションを実現します。

ベストプラクティス

技術非依存性: チームが独立してスタックを選択・アップグレードできるようにします。統合境界にはブラウザ標準(Custom Elements)を使用します。

コード分離: 共有グローバルとランタイム依存関係を避けます。CSS、イベント、ストレージに名前空間を設定し、衝突を防ぎます。

堅牢性: 回復力とパフォーマンスのために、ユニバーサル/サーバーサイドレンダリングとプログレッシブエンハンスメントをサポートします。

通信パターン: Micro-Frontends間の疎結合な通信には、カスタムAPIよりもネイティブブラウザイベントを優先します。

共有コンポーネントライブラリ: 視覚的一貫性のために中央ライブラリを使用しますが、競合を防ぐカプセル化を確保します。

フレームワークガバナンス: 断片化を避けるために最小限のフレームワークと規約のセットに合意しつつ、チームの柔軟性をサポートします。

パフォーマンス監視: Micro-Frontends全体でバンドルサイズ、ロード時間、ランタイムパフォーマンスを追跡し、最適化の機会を特定します。

リポジトリ構成

Monorepo: すべてのMicro-Frontendsを単一リポジトリに配置。

• 長所: コード共有が容易、アトミックコミット、統一されたCI/CD
• 短所: 扱いにくくなる可能性、結合のリスク、ビルドが遅い

Multirepo: 各Micro-Frontendを独自のリポジトリに配置。

• 長所: 強力な自律性、独立したパイプライン
• 短所: コード共有が困難、リポジトリ間の変更調整が難しい

Metarepo: 複数のリポジトリと調整用のメタリポジトリを組み合わせたハイブリッドアプローチ。

• 長所: 自律性と共有ガバナンスのバランス
• 短所: 追加のツールと調整が必要

使用すべき場合

適切なシナリオ:

• 明確なビジネスドメインを持つ大規模で複雑なWebアプリ
• 独立したデリバリーサイクルを必要とする複数のチーム
• レガシーモノリスからの段階的移行
• 長期的な保守性と機能進化の要件

不適切なシナリオ:

• 小規模または単一チームのアプリケーション
• 不安定または急速に進化するビジネスドメイン
• 組織的オーバーヘッドがモジュール化の利点を上回る場合
• 要件が変化する迅速なプロトタイピングやスタートアップ

ユースケース

Eコマース: 商品カタログ、カート、アカウントを個別のMicro-Frontendsとして、各ドメインに特化したチームを可能にします。

フードデリバリー: 閲覧、注文、ユーザープロフィールを個別のMicro-Frontendsとして、特定のワークフローに最適化します。

エンタープライズポータル: ダッシュボード、分析、管理モジュールを独立して構築・デプロイし、異なるリリースサイクルをサポートします。

SaaSプラットフォーム: チームの自律性を維持しながら、独立して開発された機能を単一の製品に統合します。

アーキテクチャ比較

参考文献

• Martin Fowler: Micro Frontends
• Micro-Frontends.org
• Wikipedia: Micro Frontend
• ThoughtWorks Technology Radar
• Webpack: Module Federation
• Google: Custom Elements
• Nginx SSI Documentation
• MDN: CustomEvent
• YouTube: Edge-Side Includes