マイクロフロントエンドとは、独立して所有および展開可能なフロントエンドアプリケーションを組み合わせたユーザーインターフェイスです。 2016, です。 2024 調査では 23.6% % 75.4% in 2022. %
の回答者が
のデータによると 問題に直面しているかもしれません。3つの製品チームが共通のフロントエンドリポジトリを共有し、同じリリーストレインを待ちます。ただし、1チームがチェックアウトを変更し、もう1チームがプロフィールを更新し、3チーム目がマーケティングページを調整している場合でも。
マイクロフロントエンドアーキテクチャは、チームが独立して所有、テスト、リリースできるようにするために、製品エリアを分離します。ユーザーはまだ1つのアプリケーションを経験します。
- マイクロフロントエンドの概念を理解する
- マイクロフロントエンドアーキテクチャのしくみ
- コアマイクロフロントエンドパターンの比較
- 利点、トレードオフ、そして潜在的なリスク
- テスト、デプロイ、移行の実践
- Capacitor と Electron でマイクロフロントエンドを使用する
- マイクロフロントエンドを選択する時
マイクロフロントエンドの概念を理解する
1 つのフロントエンドから複数の所有アプリケーションまで
A traditional frontend is often a single repository, a single build, and a single deployment boundary. Even if the code is divided into clean feature folders, the teams behind those folders may still depend on the same pipeline and release schedule. A small change in one area can trigger a full application build, shared regression testing, and coordination across every team.
A micro frontend divides the browser application into ビジネス機能. The checkout team owns checkout, the profile team owns account settings, and the marketing team owns promotional content. Each slice can have its own codebase, delivery process, and release cadence, then become part of a larger experience through a shell or composition layer.
マーティン・フラワーの定義では 独立して配信可能なフロントエンドアプリケーションを組み合わせて大きなシステムを作るアーキテクチャのスタイル kare wa kihon マイクロフロントエンドアーキテクチャガイド. The phrase “independently deliverable” carries more weight than “frontend applications.” Without an independent deployment boundary, you may have a modular monolith rather than a micro frontend system.
アプリケーションを構成する小さなフロントエンド
デパートを想像してみましょう。店舗の前面を管理するチーム、チェックアウトカウンターを操作するチーム、返品を取り扱うチームがそれぞれ別々に活動しています。顧客は1つの店舗を利用できますが、各エリアには異なるプロセス、責任、スタッフが存在します。マイクロフロントエンドは同様に機能します:ブラウザは1つの製品体験をレンダリングしますが、複数のチームは背景で異なるインターフェイスエリアを操作しています。
アプリケーションシェルは通常、共有フレーム、ナビゲーション、認証コンテキスト、ルート決定を所有します。マイクロフロントエンドはそのフレーム内に存在するページまたは機能を所有します。チームは境界を合意する必要がありますが、実装の詳細を共有する必要はありません。
マイクロフロントエンドとは ブラウザにマイクロサービス思考を適用 より広範な実用的な概要については、NerdifyによるスケーラブルなWeb開発の概要を参照してください。マイクロフロントエンドは、隣接するアプローチであるプラグインアーキテクチャと比較することで、より実用的な理解を得ることができます。プラグインアーキテクチャの概要は、この プラグインアーキテクチャガイドで説明されています。 マイクロサービス思考をブラウザに拡張した後、.
マイクロフロントエンドの重要な教訓は、すべてのインターフェイスのデフォルトアップグレードではないことです。チームの境界とリリースの境界が実際の痛みを生み出している場合にのみ意味があります。コストは、独立性を管理するためにさらに契約、資産、実行時エラーモード、運用ツールを管理することの価値がある場合にのみ正当化されます。
マイクロフロントエンドアーキテクチャのしくみ
シェルとそのフラグメント
通常のシステムは、 アプリケーションシェル、またはコンテナーやオーケストレータと呼ばれるものです。シェルは共通レイアウトをレンダリングし、ルーティングを確立し、認証コンテキストを提供し、共有インターフェイス要素であるナビゲーションや通知を提供します。また、どのマイクロフロントエンドをロードするかと、それをマウントする場所を決定することも責任があります。
各フラグメントは独立して管理されるアプリケーションです。別のリポジトリに存在する場合、独自のCIパイプラインを使用し、独自のバージョンを公開し、バンドル、フラグメント、ウェブコンポーネント、リモートモジュールを公開することができます。シェルはブラウザでそれらの部分を組み合わせます。ページがロードされたときまたはルートがそれらを必要とするときです。
境界は、チームがそれに頼ることができる場合にのみ役に立ちます。シェルと各フラグメントには、マウント動作、ルートの所有権、ロード状態、エラー処理、デザイントークン、アクセシビリティの期待、サポートされる依存性バージョンをカバーする明示的な契約が必要です。
実践的なルール: フレームワークを意図的に共有し、視覚的原子を共有しない。同一フレームワークを使用するチームがいるからといって、実行時実装の詳細を共有する必要はない。
モノリシックを再現せずにコミュニケーションをとる
フラグメント間でコミュニケーションが必要な場合があります。チェックアウトのスライスはユーザーがサインインしたことを知りたいかもしれませんが、プロフィールのスライスはアカウントが更新されたイベントを公開したいと思います。チームはカスタムブラウザイベント、共有ストア、URLパラメータ、またはインジェクションサービスを使用できます。
すべてのオプションは、異なる結合プロファイルを作成します:
- カスタムイベント 所有権を分離するが、チームはイベント名、ペイロードの形状、タイミングをドキュメントする必要があります。
- 共有ストア 調整された状態を簡素化しますが、中央の依存グラフを再現する可能性があります。
- URLパラメータ ナビゲーションと共有状態に適していますが、すべてのインタラクションには適していません。
- インジェクションサービス 制御された機能を提供しますが、シェルはサービス契約を維持する必要があります。
アプリケーション全体に属するものだけがシェルで管理されるべきだ。シェルが各フラグメントの状態とビジネスルールを管理するようになると、複雑なデプロイメントプロセスを持つ分散型モノリシックになる。
マイクロサービスと同様に、Fowlerが記録した歴史的進化は、このパターンがよくマイクロサービスと比較される理由を説明している。両方のアプローチは、所有権と配信を分離するが、マイクロフロントエンドはブラウザインターフェイスにその独立性を適用する。現代のツールキットでは、 モジュールフェデレーションの使用が目立つ一方で、ライフサイクルベースのアプリケーション登録を求めるチームにとっては、シングル-スパがオーケストレーションオプションとして残っている。 例えば、チェックアウトチームが支払いフローを修正した場合、カタログチームはカタログのフラグメントを再構築せずにリリースすることができる。シェルは各承認されたスライスを実行時構成に従ってロードするため、独立した配信境界、ではなく、視覚的な別のコンポーネントの外観ではなく、独立した配信境界がアーキテクチャの主な利点である。
チームが取り巻くプラットフォームを評価する際にも、
フロントエンドシステムのアプリケーションインフラストラクチャを考慮する必要がある。リポジトリやフレームワークだけでは、信頼性の高い組み合わせを提供できないからだ。 マイクロフロントエンドのパターンを比較するどの統合機構も、マイクロフロントエンドのすべての問題を解決しない。隔離、通信、依存性共有、ブラウザの動作、運用上の所有権を比較するのではなく、最も流行りのツールを選択するのではなく、
パターン
隔離
| context | Isolation | 統合モデル | 共有依存関係 | パフォーマンス | ベストフィット |
|---|---|---|---|---|---|
| フレーム | 強力なプロセスとドキュメント隔離 | クロスフレームメッセージングを使用した埋め込みドキュメント | デフォルトではなし | ロードと通信のオーバーヘッドを追加 | 信頼できない、古い、または高度に隔離されたエクスペリエンス |
| Webコンポーネント | エンベロープされた要素と、使用されている場合のShadow DOMスタイリング | Shellによってマウントされるカスタム要素 | 共有デザイントークンとブラウザAPI | コンポーネントの重量に依存するが予測可能 | フレームワークの柔軟性を必要とする標準化されたチーム |
| モジュールフェデレーション | モジュール間のランタイム隔離 | リモートモジュールのロードとマウント | 依存関係の明示的な交渉またはバンドル | ロードと削除の制御が行われる場合に効率的 | 独立したリリースを持つ、密接に統合されたアプリケーション |
| single-spa | オーケストレーション境界としての隔離モデルではなく | ライフサイクルホックを通じて登録されたアプリケーション | アプリケーションとルート設定に依存 | ロードルールとフレームワークの組み合わせに依存 | ルートベースのアクティベーションを使用したマルチフレームワークオーケストレーション |
フレーム
この比較で最も強力な境界を与えるiframe。埋め込まれたアプリケーションには独自のドキュメント、スタイル、JavaScript環境があり、ホストページのDOMを誤って変化させることはない。クロスウィンドウメッセージングは制御されたコミュニケーションパスを作成できる。
その隔離により、iframeはレガシーシステム、パートナーエクスペリエンス、保持する必要があるコンテンツに便利である。コストは、レスポンシブレイアウト、ナビゲーション、アクセシビリティ、フォーカス管理、共有認証に現れる。チェックアウトiframeは、ホストと埋め込まれたアプリケーションが慎重に調整しないと、外国語の表面のように感じられる。
ウェブコンポーネント
ウェブコンポーネントは、すべてのチームが同じフレームワークを採用する必要がないため、ブラウザの標準を使用する。カスタム要素は安定したマウントサーフェイスを定義し、Shadow DOMはスタイルの漏洩を制限できる。シェルは依然としてアプリケーションルーティング、ロード状態、エラーバウンダリー、共有デザイントークンを処理する必要がある。
このオプションは、ブラウザがすべてのスライスでアプリケーションランタイムをロードする必要がないため、フレームワークの柔軟性をチームが望むときにうまく機能する。依存サイズ、状態の共有、または統治を自動的に解決することはない。カスタム要素は依然として大きなアプリケーションを含むことができ、その独自の運用複雑さがある。
モジュール連邦
モジュール連携、Webpack 5で導入され、ViteやRspackなどのツールでサポートされている。実行時にはリモートエントリからコンパイル済みモジュールをロードし、共有コンポーネントと調整されたナビゲーションを自然に感じさせるようにする緊密な統合を提供します。
その利便性は責任をもたらします。チームは互換性のある公開インターフェイス、共有依存関係のルール、リモートバージョン管理、リモートがロードできない場合の復旧計画が必要です。 モノリシックアーキテクチャとマイクロサービスアーキテクチャの違い 提供される分離の独立した展開と単純なcode分解の有用な背景
シングルスパ
シングルスパはフレームワーク非依存のオーケストレーターとして機能します。チームはアプリケーションとライフサイクルハックを登録し、ルート構成はルートまたは他の条件に基づいてアクティブ化します。異なるフレームワークで構築されたアプリケーションを調整できますが、契約、依存関係ポリシー、パフォーマンス予算、セキュリティコントロールの必要性はありません。
チームはこれらのメカニズムを組み合わせることができます。たとえば、シングルスパルートはルートを調整し、モジュール連携はリモートモジュールを提供し、Webコンポーネントは公開マウントサーフェイスを定義することができます。その組み合わせは強力ですが、追加されたレイヤーごとに開発者が理解しテストする必要がある動作の数が増えます。
利点とトレードオフ、そして隠れたリスク
マイクロフロントエンドは境界を越えた決定を実行します。リリースの爆発半径を減らし、チームに制御を与えますが、システムはより多くのアーティファクト、契約、実行条件を管理する必要があります。
| Dimension | 利点 | トレードオフ / 隠れたリスク |
|---|---|---|
| チームの自律性 | チームはビジネススライスを端から端まで管理する | チームは別々のパイプライン、オンコールの所有権、リリースの規律を維持する必要があります |
| デプロイ | フラグメントはフルインターフェイスを再構築することなく配信できます | リリースは非原子化されるため、互換性のないバージョンが生産環境で遭遇する可能性があります |
| 障害の隔離 | リモートの障害がフォールバックによって隔離される | エラー境界が劣悪なまま、ナビゲーションや重要な旅程は使えなくなる |
| パフォーマンス | リレッジロードと初期バンドルの小さなサイズにより、一般的なフローをサポートできます。 | より多くのリクエスト、重複したフレームワーク code, そしてリモート初期化は実行時パフォーマンスに悪影響を与える |
| 実行時間パフォーマンスに悪影響を与えるのは、多くの要求、重複したフレームワーク `__CAPGO_KEEP_0__`、リモート初期化である | 技術選択 | 境界が許可する範囲で、チームは異なるフレームワークを使用できる |
| Security | セキュリティ | The shell may execute remote code that it hasn’t adequately verified. |
| 境界は直接実装の共有を制限する | シェルは、十分に検証されていない `__CAPGO_KEEP_0__` を実行する可能性がある | 設計システム、依存関係のルール、契約書、プラットフォームのサポートには、継続的な調整が必要です。 |
パフォーマンスの請求書
独立したスライスは通常、別々にビルドされたアセットを生成します。注意深いロードルールなしでブラウザは、さらにファイルを要求し、codeを初期化し、または重複したフレームワーク依存関係をダウンロードする可能性があります。マイクロフロントエンドのパフォーマンスガイドラインは、オンデマンドロード、依存関係の共有、モジュールレベルのキャッシュ、エラーの分離を強調しています。
実用的設計は、既存のアプリケーションのベースラインから始まります。ルートの起動、バンドルの組み立て、リモートロード、初期化、ユーザーに視覚化されるエラーを測定します。次に、シェルと各高トラフィックスライスの予算を設定します。Lazyロードは、長いリモートモジュールのチェーンでブロックされない批判的ジャーニーを実行するアプリケーションにのみ役立ちます。
セキュリティの隙間
リモートモジュールは、別々のリポジトリを持つことによって自動的に安全ではありません。シェルは、検証されていないcodeを実行し、フロントエンドの境界はAPIやトークンサービスでの認証を置き換えることはありません。 セキュリティに焦点を当てたマイクロフロントエンド分析 信頼、署名、整合性チェック、認証が設計上の注意を必要とするのは、チームが実行時codeを配布する前に、明らかです。
バージョンのずれは別のリスクのクラスを生み出します。フラグメントは単独で動作するかもしれませんが、異なるシェルバージョン、共有ライブラリ、デザイントークンセット、イベントペイロードと遭遇すると失敗する可能性があります。 Nxのアーキテクチャガイドライン マイクロフロントエンドを理解する
アーキテクチャはコーディネーションを削除するのではなく、リリース会議から契約、自動化、監視、ガバナンスに変える。
チームは共有依存性の明確な所有権、アクセシビリティレビュー、インシデント対応、ロールバック決定が必要です。プラットフォーム層の所有権が誰にもない場合、各製品チームは組み合わせ方を独自に解決し、ユーザーは結果として生じる不一致を1つの壊れたアプリケーションとして経験します。
テスト、デプロイ、移行の実践
テストはアプリケーションが実行される方法を反映する必要があります。フラグメントが単体テストを通過しても、シェルが提供する変更されたルート、予想外の認証状態、または異なる共有依存性の場合に失敗する可能性があります。
層状のテストシステムを構築する
各フラグメントの孤立したテストから始めます。これらのテストはレンダリング、ビジネスルール、キーボード動作、ロード状態、ローカルエラー処理を検証しますが、フルシェルが必要ありません。
契約テストは上位にあります。契約テストはシェルとフラグメントのインターフェイスを検証し、mount入力、ルートパターン、発行されたイベント、期待されるペイロード、認証の仮定、フォールバック動作を含みます。契約テストは、1つのチームが別のチームが消費するインターフェイスを変更した場合に、生産前に失敗するようにする必要があります。
シェル統合テストでは、実際のフラグメントアーティファクトを代表的な組み合わせで読み込む。ルーティング、認証トランジション、共有ナビゲーション、ロード失敗、バージョン組み合わせをカバーする必要がある。エンドツーエンドテストは、複数の独立して配信されたスライスを通じて、製品を閲覧する、サインインする、チェックアウトを完了するなどの完全な旅を検証するため、上位に置く必要がある。
リリースサーフェイスを制御する
バージョンマニフェストを使用して、シェルが読み込む正確なフラグメントアーティファクトを特定できるようにする。マニフェストは、リモートリリースがエラーを引き起こす場合に、オペレータが知られている良好なバージョンを固定できる場所を提供する。
有用なコントロールは次のとおりである。
- 機能フラグ: 内部ユーザーや選択されたルートで新しいフラグメントを有効化する前に、広範な露出を避ける。
- カニバリーデリバリー: 新しいアーティファクトに限られたユーザーを指示し、ブラウザエラー、ロード失敗、重要なビジネスアクションを監視する。
- 観察可能なバンドル: ログ、トレース、クライアントエラーにリリース識別子を追加して、責任のあるチームが失敗したフラグメントを特定できるようにする。
- ロールバックパス: 前の互換性のあるアーティファクトを保持し、再構築をオペレーショナルなアクションにし、手動の再構築をしない。
チームは、シェルとフラグメントを一緒に、生産的な環境でテストする。成功したローカル実行は、ユーザーにとって正しく動作するコンテンツ配信パス、キャッシュ、認証トークン、リモートマニフェストを証明しない。 展開自動化の実践 は、繰り返しプロモーションとロールバックワークフローをサポートするが、まだ明確な所有権が必要である。
ドメインを一つずつ移行する
ストランガー移行は、モノリシックから新しいフラグメントに機能を一つずつ移行する。機能フラグは並行実行をサポートし、チームは新しいパスと既存の実装を比較することができる。新しいルートをデフォルトにする前に、チームは比較を実行できる。
コマースアプリケーションを考えてみよう。カタログ、会員、チェックアウトのチームがそれぞれ別々のドメインを持っている。シェルはナビゲーションと認証を所有し、カタログチームは商品検索を所有し、会員チームはプロファイル設定を所有し、チェックアウトチームはカートと支払いフローを所有している。各チームは独自のアーティファクトを公開し、ルートとイベントの契約を保護する契約テストを実行している。
低リスクのドメインから始め、フラグを立てて公開し、リアルなジャーニーを通じて監視する。チームがドメインを展開、診断、ロールバックできるようになるまで、組織全体がリリースを調整する必要がないようにする。
CapacitorとElectronでマイクロフロントエンドを使用する
A Capacitor または Electron アプリケーションはブラウザ シェルに別のシェルを追加します。 Capacitor はウェブ code をネイティブモバイル WebView 内に配置し、Electron はウェブ code をデスクトップレンダラー プロセス内に配置します。どちらの場合も、アプリはローカルシェルをロードできます。このシェルは実行時、選択されたフロントエンドアーティファクトを取得するのではなく、ネイティブバイナリに組み込まれたすべてのインターフェイス変更を埋め込むのではなくします。
その配置は、有用なリリース分割を生み出します。ネイティブ機能、権限、ブリッジ code はインストール済みアプリケーションに紐付けられます。ウェブ所有の表面、例えばアカウント、ヘルプ、カタログ、または設定は、別の配信パスを遂行できます。シェルは、フラグメントの元の場所を決定する必要があります。また、承認されたバージョンを決定し、フェッチまたは検証ステップが失敗した場合にアプリケーションが何をするかを決定する必要があります。
ライブアップデートとロールバック
ライブアップデートシステムはフロントエンドアーティファクトをリリース可能なソフトウェアとして扱う必要があります。 署名されたバンドルを配信し、有効化前に署名を検証し、
ステージドロールアウト用のリリースチャンネルをサポートし、
Capgoは、この配信モデルの一つの選択肢です。CapacitorJSおよびElectronアプリ用のライブアップデートプラットフォームは署名されたWebバンドルを公開し、ターゲットチャンネルをサポートし、起動次の更新を適用し、ログ、バージョン履歴、採用率、失敗率のメトリクス、ロールバック保護、CI/CD統合、およびAPIを提供します。nativeブリッジを検討しているチームは、nativeブリッジを理解する必要があります。 CapacitorはWebとnativecodeをどのように接続するかを理解する必要があります。.
ネイティブシェルの変更
ネイティブラッパーは、ブラウザのみのアプリケーションが直面しない制約を導入します:
- 接続性: デバイスがオフラインの場合、フラグメントが利用できない可能性があるため、シェルはキャッシュされたアーティファクトまたはローカルフォールバックが必要です。
- 互換性: Webバンドルは、インストール済みのバイナリがサポートしないnativeブリッジの動作に依存している可能性があります。
- セキュリティ: リモートcodeは、認証、整合性チェック、およびアプリケーションコンテキストで許可された必要があります。
- 復旧: バンドルが無効である場合、即時ストア配布を必要とせずに機能するバージョンを復元できるように、シェルは無効なバンドルを拒否する必要があります。
- セッションの安全性: 支払いまたはフォームフローの更新中に不一致の状態が生じる可能性があるため、次の起動時にはアクティブな作業を中断するのではなく、安全性が高くなります。
このモデルは、配信プラットフォームが原子的なアクティブ化と詳細なリリースメトリクスを提供する場合にロールバックを強化します。ただし、チームがWebの独立性がネイティブの互換性計画を排除することを前提としている場合、技術的多様性はアーキテクチャを複雑にします。ネイティブのシェルは契約境界であり、各フラグメントはそれを尊重する必要があります。
マイクロフロントエンドを選択する時期
マイクロフロントエンドを選択する時期は 独立したデプロイが実際の要件である場合複数のチームが明確に分離された製品サーフェイスを所有している場合、または長期的な移行中、古いと新しいインターフェイスが共存する必要がある場合、または技術的多様性がフレームワークの境界を必要とする場合、独立したデプロイが実際の要件である場合
マイクロフロントエンドを避けるべき状況は
小規模のチームが1つのフロントエンドを所有できる場合、ドメインが共有する拘束力のある状態がある場合、または組織が信頼できるCI、観察性、契約テスト、ロールバック手順を備えていない場合です。分散インターフェイスがそれらの基盤を備えていない場合、自律性が生まれるのではなく、エラーの場所が増えるだけです。
- Ownership: 所有権:
- 境界: シェルとスライスは、安定した契約を通じて通信できるか?
- リリースの必要性: チームは独立してデプロイする必要があるか?
- 運用準備: フラグメントを監視、テスト、固定、ロールバックできるか?
- ユーザー価値: 分割がパフォーマンスや一貫性を損なわないように、配信を改善するか?
まず、ヘルプコンテンツや設定などの低リスクのエリアから始めましょう。マウント契約、ルートの所有権、イベント、デザイントークン、フォールバック動作、バージョンポリシーを定義してください。機能フラグを使用してデプロイし、追加のバンドルとロードコストを測定し、すべての新しいチャネル、マニフェスト、依存性ルール、ロールバックパスをドキュメントしてください。
マイクロフロントエンドは、組織的およびリリースの独立性のためのツールであり、自動的にフロントエンドの質の向上にはなりません。リリースの問題が小さければ、モジュラーのモノリシティがより良い答えになるかもしれません。コーディネーションの問題が大きく持続的であれば、慎重に管理されたマイクロフロントエンドアーキテクチャはチームに必要な自律性を与えることができます。
If you’re evaluating micro frontends for a Capacitor or Electron product, Capgo can help you deliver signed web bundles through controlled channels, activate updates on the next launch, and recover through rollback protection. Visit Capgo to review its delivery, observability, and API options before you design your fragment release process.
