マイクロフロントエンドとは

と 2016, and a 2024 調査報告書によると 23.6% 前年、回答者 75.4% の 2022. State of Frontendデータ

あなたはすでにこの問題に直面しているかもしれません。3つの製品チームが1つのフロントエンドリポジトリを共有し、同じリリーストレインを待ちます。1チームがチェックアウトを変更し、もう1チームがプロフィールを更新し、3チームがマーケティングページを調整している場合でも、ユーザーは1つのアプリケーションを経験できます。

その区別は重要です。マイクロフロントエンドは、より小さなフォルダ、コンポーネント、またはバンドルではありません。主な目的は 組織的およびリリースの独立性、技術的境界によって所有権を明確にすることでサポートされています。アーキテクチャは、調整のボトルネックを削減できますが、実行時統合、依存性管理、テスト、セキュリティ、パフォーマンスの責任も導入します。

目次

• マイクロフロントエンドの概念を理解する
  • 1つのフロントエンドから複数の所有アプリケーション
  • 構成されたストアのアナロジー
• マイクロフロントエンドアーキテクチャのしくみ
  • シェルとその断片
  • モノリシックを再構築せずにコミュニケーションする
• コアマイクロフロントエンドパターンの比較
  • フレーム
  • Webコンポーネント
  • モジュールフェデレーション
  • single-spa
• 利点、トレードオフ、そして隠れたリスク
  • パフォーマンスの請求書
  • セキュリティの隙間
• テスト、デプロイ、移行の実践
  • マイクロフロントエンドを使用した __CAPGO_KEEP_0__ と Electron の構築
  • リリースの対象範囲を制御する
  • ドメインごとに一つずつ移行する
• マイクロフロントエンドを使用した Capacitor と Electron の構築
  • ライブ更新とロールバック
  • ネイティブシェルの変更
• マイクロフロントエンドを選択するタイミング

マイクロフロントエンドの概念を理解する

1 つのフロントエンドから複数の所有するアプリケーションに

通常のフロントエンドは 1 つのリポジトリ、1 つのビルド、1 つのデプロイメントの境界を持つことが多い。 code が機能領域ごとにきれいに分割されている場合でも、機能領域の背後にあるチームは依然として同じパイプラインとリリーススケジュールに依存している可能性がある。 1 つの領域で小さな変更が行われた場合、全体のアプリケーションビルド、共有リグレッションテスト、すべてのチーム間の調整が必要になる。

ブラウザアプリケーションをビジネス能力に基づいて分割する マイクロフロントエンドの概念各チームは、チェックアウト、プロフィール設定、プロモーショナルコンテンツをそれぞれ管理します。

マーティン・フラワーの定義では 「独立して配信可能なフロントエンドアプリケーションを組み合わせて、より大きな体験を形成するアーキテクチャ的スタイル」 である。 彼の基礎となるマイクロフロントエンドアーキテクチャガイド

「独立して配信可能」という言葉は、「フロントエンドアプリケーション」という言葉よりも重みがあります。

独立したデプロイメント境界がなければ、モジュラーなモノリシックではなく、マイクロフロントエンドシステムになりません。

ストレスのあるオフィス従業員が、紙を握りながら、異なるマイクロフロントエンド開発チームを表すイメージです。

この用語は、2016年11月のThoughtworksのTechnology Radarで拡張された。 マイクロサービス思考をブラウザに拡張した。 ThoughtworksがTechnology Radarで強調した後、FowlerはAssessからTrialに進み、最終的にAdoptに進みました。これは、パターンの発展から、より確立されたアーキテクチャーオプションへの移行を説明しています。 Nerdifyによるより広範な実用的な概要を得るには、scalable web開発のためのパターンを、隣接するアプローチであるプラグインアーキテクチャと比較することが役立ちます。このプラグインアーキテクチャガイドで議論されています。 重要な教訓は、マイクロフロントエンドは、すべてのインターフェイスのデフォルトアップグレードではありません。.

チームの境界とリリースの境界が実際の痛みを生み出している場合にのみ意味があります。

独立性が管理するために、コントラクト、資産、実行時エラー、運用ツールのコストが正当化されます。

マイクロフロントエンドアーキテクチャのしくみ

シェルとそのフラグメント 通常、機能するシステムはアプリケーションシェル、またはコンテナーやオーケストレータと呼ばれるものから始まります。シェルは共通レイアウトをレンダリングし、ルーティングを確立し、認証コンテキストを提供し、共有インターフェイス要素であるナビゲーションや通知を提供します。シェルはどのマイクロフロントエンドをロードするか、そしてそのフラグメントをどこにマウントするかを決定します。

各フラグメントは独立して管理されるアプリケーションです。 それぞれは別々のリポジトリに存在し、独自のCIパイプラインを使用し、独自のバージョンを公開し、バンドル、フラグメント、Webコンポーネント、またはリモートモジュールを公開することができます。 シェルはブラウザでそれらの部分を組み合わせます。 それがページが読み込まれたとき、あるいはルートがそれらを必要とするときです。

境界は有用である限り、チームはそれに頼ることができます。 シェルと各フラグメントには、モントの動作、ルートの所有権、ロード中の状態、エラーハンドリング、デザイントークン、アクセシビリティの期待、サポートされている依存関係のバージョンについて明示的な契約が必要です。

実践的なルール: 契約と視覚的原則を意図的に共有する。 ただし、2つのチームが現在同じフレームワークを使用しているためだけに実行時実装の詳細を共有しない。

モノリシムを再現せずにコミュニケーション

フラグメント間でコミュニケーションが必要な場合があります。 チェックアウトのスライスはユーザーがログインしたことを知りたい場合があり、プロフィールのスライスはアカウントが更新されたイベントを公開したい場合があります。 チームはカスタムブラウザイベント、共有ストア、URLパラメータ、またはインジェクションされたサービスを使用できます。

各オプションは異なる結合プロファイルを作成します:

• カスタムイベント 所有権を分離し、チームはイベント名、ペイロードの形状、タイミングをドキュメント化する必要があります。
• 共有ストア 調整された状態を簡素化しますが、依存関係グラフを再現する可能性があります。
• URLパラメータ ナビゲーションと共有状態ではうまく機能しますが、すべてのインタラクションには適していません。
• インジェクションされたサービス 制御された機能を提供しますが、シェルはサービス契約を維持する必要があります。

シェルは、全体のアプリケーションに属するものだけを調整するべきです。各フラグメントの状態とビジネスルールをすべて管理するようになったら、複雑なデプロイメントプロセスを持つ分散型モノリシックアプリケーションになってしまいます。

フォウラーが記録した歴史的進化は、パターンがマイクロサービスと比較される理由を説明しています。両方のアプローチは、所有権と配信を分離していますが、マイクロフロントエンドは、ブラウザインターフェイスにその独立性を適用しています。現在のツールキットでは モジュールフェデレーションの使用 シングル-SPAは、ライフサイクルに基づくアプリケーション登録を希望するチームにとってオーケストレーションオプションとして残っています。

例えば、チェックアウトチームは、決済フローの修正をリリースすることなく、カタログフラグメントを再構築する必要がなくなるでしょう。カタログチームは、シェルが実行時設定に基づいて各アプロードされたスライスをロードするため、より遅いリリースキャデンスで進められるでしょう。その独立した配信境界、視覚的な分離されたコンポーネントの外観ではなく、主な利点はアーキテクチャです。

評価しているチームは、周辺プラットフォームを考慮する必要があります。 フロントエンドシステムのアプリケーションインフラ, リポジトリとフレームワークだけでは、信頼できる組み合わせを提供できません。

比較するコアマイクロフロントエンドパターン

マイクロフロントエンドの問題を解決するには、単一の統合メカニズムがすべての問題を解決することはありません。隔離、通信、依存性共有、ブラウザの動作、運用管理の所有権を比較して、最も流行りのツールを選択するのではなく、選択してください。

IFrames

IFrameはこの比較で最も強い境界を提供します。埋め込まれたアプリケーションには独自のドキュメント、スタイル、JavaScript環境があり、ホストページのDOMに意図せずに変化させることはありません。クロスウィンドウメッセージングは制御されたコミュニケーションパスを作成できます。

IFrameは、レガシーシステム、パートナーエクスペリエンス、保持する必要があるコンテンツのために隔離を提供します。コストは、レスポンシブレイアウト、ナビゲーション、アクセシビリティ、フォーカス管理、共有認証に現れます。チェックアウトIFrameは、ホストと埋め込まれたアプリケーションが慎重に調整しないと、外国語の表面のように感じることがあります。

Webコンポーネント

ブラウザの標準を使用するWebコンポーネントは、すべてのチームが同じフレームワークを採用する必要がない。カスタム要素は安定したマウントサーフェイスを定義し、Shadow DOMはスタイルの漏洩を制限できる。

このオプションは、ブラウザが各スライスごとに全体のアプリケーションランタイムを読み込む必要がないため、フレームワークの柔軟性をチームが望む場合にうまく機能する。依存関係サイズ、状態の通信、またはガバナンスを自動的に解決するわけではない。カスタム要素は依然として大きなアプリケーションを含むことができ、その独自の運用複雑さを持ちうる。

モジュール連携

モジュール連携は、Webpack 5で導入され、ViteやRspackなどのツールによってサポートされている。実行時にはリモートエントリからコンパイル済みモジュールを読み込む。共有コンポーネントや調整されたナビゲーションがiframesと比べてより自然に感じられるようにするため、緊密な統合を提供する。

その利便性は責任をもたらす。チームは互換性のある公開インターフェイス、共有依存関係のルール、リモートバージョンの管理、リモートが読み込めない場合の復旧計画が必要になる。 モノリシックアーキテクチャとマイクロサービスアーキテクチャの差異 単一のアプリケーションを複数のサービスに分割することの有用な背景を提供し、単純なcodeの分解とは区別される。

単一のアプリケーション

single-spaはフレームワーク非依存のオーケストレーターとして機能します。 チームはアプリケーションとライフサイクルハックを登録し、ルート設定はルートやその他の条件に従ってアクティブ化します。 それらは異なるフレームワークで構築されたアプリケーションを調整できますが、契約、依存性ポリシー、パフォーマンス予算、またはセキュリティコントロールの必要性はありません。

チームはこれらのメカニズムを組み合わせることができます。 たとえば、single-spaルートはルートを調整し、Module Federationはリモートモジュールを提供し、Web Componentsはパブリックマウントサーフェイスを定義することができます。 これらの組み合わせは強力ですが、開発者が理解しテストする必要がある動作の数が増えます。

利点とトレードオフ、そして潜在的なリスク

次元

パフォーマンスの請求書

独立したスライスは通常、別々にビルドされたアセットを生成します。注意深いロードルールなしでブラウザは、さらにファイルを要求し、さらに code を初期化したり、重複したフレームワーク依存関係をダウンロードしたりする可能性があります。マイクロフロントエンドのパフォーマンスガイドラインは、オンデマンドロード、注意深い依存性共有、モジュールレベルキャッシュ、エラー隔離を強調しています。

実用的な設計は、既存のアプリケーションのベースラインから始まります。ルートの起動、バンドルの組成、リモートロード、初期化、ユーザーに視覚化されるエラーを測定します。次に、シェルと各高トラフィックスライスの予算を設定します。Lazyロードは、長いリモートモジュールの連鎖で批判的な旅をブロックしない限り、有効ではありません。

セキュリティの隙間

リモートモジュールは、別のリポジトリを持つことによって自動的に安全ではありません。シェルは、十分に検証されていない code を実行する可能性があり、フロントエンドの境界はAPIまたはトークンサービスでの認証を置き換えるものではありません。 セキュリティに焦点を当てたマイクロフロントエンド分析 信頼、署名、整合性チェック、認可がチームが実行時 code を配布する前に設計に注目する必要があることを強調しています。

バージョンのずれは別のリスクのクラスを作成します。フラグメントは単独で動作するかもしれませんが、異なるシェルバージョン、共有ライブラリ、デザイントークンセット、イベントペイロードと遭遇すると失敗する可能性があります。 Nxのアーキテクチャガイドライン identifies coordination, environment configuration, application efficiency, and reusability as continuing challenges.

アーキテクチャはコーディネーションを削除するのではなく、リリースミーティングから契約、自動化、観察性、ガバナンスにコーディネーションを変える。

チームは共有依存関係の明確な所有権、アクセシビリティレビュー、インシデント対応、ロールバック決定が必要です。プラットフォーム層の所有権が誰にもない場合、各製品チームは組み合わせ方を独自に解決し、ユーザーは結果として得られる一つの壊れたアプリケーションを経験します。

テスト、デプロイメント、移行の実践

テストはアプリケーションが実行される方法を反映する必要があります。フラグメントが単体テストを通過しても、シェルが提供する変更されたルート、予期しない認証状態、または異なる共有依存関係の場合に失敗する可能性があります。

層状のテストシステムを構築する

各フラグメントの孤立されたテストから始めます。これらのテストはレンダリング、ビジネスルール、キーボード動作、ロード状態、ローカルエラー処理を検証しますが、フルシェルが必要ありません。

契約テストは上位にあります。契約テストはシェルとフラグメントの間のインターフェイスを検証し、mount入力、ルートパターン、発行されたイベント、期待されるペイロード、認証の仮定、フォールバック動作を含みます。契約テストは、1つのチームが別のチームが消費するインターフェイスを変更した場合に、生産前に失敗するようにする必要があります。

シェル統合テストは、実際のフラグメントアーティファクトを代表的な組み合わせにロードします。ルーティング、認証トランジション、共有ナビゲーション、ロード失敗、バージョン組み合わせをカバーする必要があります。エンドツーエンドテストは、複数の独立して配信されたスライスを横断して、製品を閲覧する、サインインする、チェックアウトを完了するなどの完全なジャーニーを検証する必要があります。

リリースサーフェイスを制御する

バージョンマニフェストを使用して、シェルがロードする正確なフラグメントアーティファクトを特定できるようにします。マニフェストは、リモートリリースがエラーを引き起こす場合に、オペレータが知られている良好なバージョンを固定できる場所を提供します。

有用なコントロールは次のとおりです:

• 機能フラグ: 内部ユーザーや選択されたルートで新しいフラグメントを有効化することで、広範な露出を避けることができます。
• カニバリーデリバリー: 新しいアーティファクトに限られたユーザーをダイレクトし、ブラウザエラー、ロード失敗、重要なビジネスアクションを監視することができます。
• 観察可能なバンドル: ログ、トレース、クライアントエラーにリリース識別子を追加して、責任のあるチームが失敗したフラグメントを特定できるようにします。
• ロールバックパス: 前の互換性のあるアーティファクトを保持し、再構築をオペレーショナルなアクションとしてではなく、手動で行うものとしてください。

チームは、シェルとフラグメントを一緒に、生産的な環境でテストする必要があります。ローカルで成功した実行は、ユーザーにとって正しく動作するかどうかを保証するには、コンテンツ配信パス、キャッシュ、認証トークン、リモートマニフェストなど、すべての要素をテストする必要があります。 展開自動化の実践 は、繰り返しプロモーションとロールバックワークフローをサポートできますが、まだ明確な所有権が必要です。

ドメインを一つずつ移行する

ストランガー移行では、モノリシックから新しいフラグメントに機能を一つずつ移行します。残りの部分は変更せずに、機能フラグを使用して並行実行をサポートし、チームは新しいパスと既存の実装を比較することができます。新しいルートをデフォルトにする前に、チームは比較を実行できます。

カタログ、会計、チェックアウトのチームが別々に存在するコマースアプリケーションを考えてみましょう。シェルはナビゲーションと認証を所有し、カタログチームは商品の検索を所有し、会計チームはプロフィール設定を所有し、チェックアウトチームはカートと支払いフローを所有します。各チームは独自のアーティファクトを公開し、ルートとイベントの契約を保護する契約テストを使用します。

低リスクのドメインから始め、フラグを使用して公開し、リアルなジャーニーを通じて監視します。チームがドメインを展開、診断、ロールバックすることができるまで、組織全体がリリースを調整する必要がなくなるまで、拡大するのを待ちます。

CapacitorとElectronでMicro Frontendsを使用する

A Capacitor または Electron アプリケーションはブラウザ シェルに別のシェルを追加します。 Capacitor はウェブ code をネイティブモバイル WebView 内に配置し、Electron はウェブ code をデスクトップレンダラー プロセス内に実行します。どちらの場合も、アプリはローカルシェルをロードできます。このシェルは実行時、選択されたフロントエンドアーティファクトをフェッチするのではなく、ネイティブバイナリに組み込まれたすべてのインターフェイス変更を埋め込むのではなくします。

その配置は、有用なリリース分割を生み出します。ネイティブ機能、権限、ブリッジ code はインストール済みのアプリケーションに紐付けられます。ウェブ所有の表面、例えばアカウント、ヘルプ、カタログ、または設定は、別の配信パスを追跡できます。シェルはまだ、フラグメントの元の場所を決定する必要があります、承認されたバージョンを決定する必要があります、そして、フェッチまたは検証ステップが失敗した場合にアプリケーションが何をするかを決定する必要があります。

ライブアップデートとロールバック

ライブアップデートシステムはフロントエンドアーティファクトをリリース可能なソフトウェアとして扱う必要があります。次の内容を提供する必要があります。 署名されたバンドル、検証する前に有効化する、ステージドロールアウト用のリリースチャンネルをサポートする、有効化せずにアクティブセッションを中断しないようにアップデートを次の起動時に適用する、自動ロールバック保護と原子的な復元を提供する。

それらの制御は、微小フロントエンド配信に自然にマップされます。モバイルまたはデスクトップシェルはマニフェストを固定し、互換性のあるフラグメントをフェッチし、その署名を検証し、完全なバンドルが利用可能になるまでに有効化しない限り、有効化しません。次の起動時に失敗を検出すると、アップデーターは、部分的にアップデートされたインターフェイスにユーザーを残さずに、前の知られている良好な状態に復元できます。

Capgo is one option for this delivery model. Its live-update platform for CapacitorJS and Electron apps publishes signed web bundles, supports targeted channels, applies updates on next launch, and provides logs, version history, adoption and failure metrics, rollback protection, CI/CD integrations, and an API. Teams considering the native bridge should also understand how Capacitor connects web and native code.

__CAPGO_KEEP_0__はウェブとネイティブ__CAPGO_KEEP_1__を接続する方法を理解する必要があります。

マイクロフロントエンドを使用する方法を示す図。__CAPGO_KEEP_0__またはElectronネイティブアプリシェルを使用します。

• ネイティブシェルで何が変わりますか。 ネイティブラッパーは、ブラウザのみのアプリケーションが直面しない制約を導入します:
• 接続性: デバイスがオフラインの場合、フラグメントが利用できない可能性があるため、シェルはキャッシュされたアーティファクトまたはローカルフォールバックが必要です。
• 互換性: Remote code must be authenticated, integrity-checked, and authorized for the application context.
• セキュリティー: バンドルが無効である場合、直ちにストアの配布を必要とせずに、機能するバージョンを復元できるようにする必要があります。
• セッションの安全性: 支払いまたはフォームフローの更新中に不一致の状態が生じる可能性があるため、次の起動時にアクティブな作業を中断するのではなく、安全性が高くなります。

このモデルは、配信プラットフォームが原子的なアクティブ化と詳細なリリースメトリクスを提供する場合にロールバックを強化します。ただし、チームがWebの独立性がネイティブの互換性計画を排除することを前提としている場合、Architectureは複雑になります。ネイティブのシェルは契約境界であり、各フラグメントはそれを尊重する必要があります。

マイクロフロントエンドを選択する時期

マイクロフロントエンドを選択する場合 独立したデプロイが実際の要件である場合複数のチームが明確に分離された製品サーフェイスを所有している場合、または長期的なマイグレーション中、レガシーや新しいインターフェイスが共存する必要がある場合、技術的多様性もパターンを正当化することができます。フレームワークの境界が単一のビルドできれいに収まる場合、チームが必要とする境界を提供する必要があります。

以下の要件を満たしていない場合に避けるべきです。

小さなチームが1つのフロントエンドを所有できる場合、ドメインが共有する拘束力のある状態、または組織が信頼できるCI、可観測性、契約テスト、ロールバックプロシージャを持っていない場合、分散インターフェイスは自律性を生み出すのではなく、エラーの潜在的な場所を増やします。

• シンプルな開始テストを使用してください: 所有権:
• 境界: シェルとスライスは、安定した契約を通じて通信できるでしょうか?
• リリースの必要性: チームは独立してデプロイする必要がありますか?
• 運用準備: フラグメントを監視、テスト、固定、ロールバックできますか?
• ユーザー価値: 分割により、パフォーマンスや一貫性を損なわずに配信が向上するでしょうか?

まず、ヘルプコンテンツや設定などのリスクが低い領域から始めましょう。マウント契約、ルートの所有権、イベント、デザイントークン、フォールバック動作、バージョンポリシーを定義し、機能フラグを立てて、追加のバンドルとロードコストを測定し、すべての新しいチャネル、マニフェスト、依存性ルール、ロールバックパスをドキュメントしてください。

マイクロフロントエンドは、組織的およびリリースの独立性のためのツールであり、自動的にフロントエンドの質の向上にはなりません。リリースの問題が小さければ、モジュラーのモノリシックがより良い答えかもしれません。コーディネーションの問題が大きく持続的であれば、慎重に管理されたマイクロフロントエンドアーキテクチャはチームに必要な自律性を与えることができます。

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.