翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

クロスカットの懸念に対する依存関係の管理

マイクロフロントエンドなどの分散アーキテクチャを成功させるには、意識的な依存関係管理が不可欠です。依存関係管理は、マイクロフロントエンド開発の最も困難な部分の 1 つです。

マイクロフロントエンドアーキテクチャでは、依存関係管理の 2 つの重要な側面として、大きなコードアーティファクトをクライアントに転送することによるパフォーマンス上のペナルティと、コンピューティングリソースのオーバーヘッドがあります。理想的には、組織は分散フロントエンドアーキテクチャの依存関係を維持する方法を義務付ける必要があります。

依存関係のメンテナンスを必須にするための 3 つの実行可能な戦略は、インポートマップやモジュールフェデレーションなどのウェブ標準を使用して、何も共有しないことです。他のアプローチは、分散アーキテクチャの基本原則に違反するため、アンチパターンです。

可能な場合は何も共有しない

共有なしのアプローチでは、独立したソフトウェアアーティファクト間の依存関係をまったく共有しないこと、または少なくとも統合時やランタイム時に共有しないことを前提としています。つまり、2 つのマイクロフロントエンドが同じライブラリに依存している場合、それぞれがビルド時にライブラリ内でベークし、個別に出荷する必要があります。また、各マイクロフロントエンドは、ライブラリがグローバル名前空間と共有リソースをポーリングしないことを検証する必要があります。

これは冗長性につながりますが、最大の俊敏性を備えた意識的なトレードオフです。ランタイムの依存関係を共有しない場合、チームはソリューションの範囲内でソフトウェアを進化させ、インターフェイス契約を破らない限り、どのような方法でもソフトウェアを進化させる最大限の柔軟性が得られます。

マイクロフロントエンドが共有なしの原則に従うプラットフォームでは、マイクロフロントエンドをできるだけ軽量に保つことが重要です。これには、パフォーマンスのためにマイクロフロントエンドを最適化することに熟練し、開発者エクスペリエンスのためにユーザーエクスペリエンスを犠牲にしない開発者が必要です。

コードを共有する場合

コードの共有を決定するときは、ライブラリまたはランタイムモジュールとして共有できます。たとえば、フロントエンドコアチームは CDNs を介してマイクロフロントエンド消費用のライブラリを提供します。ビジネスバリューチームは、実行時にライブラリをロードすることも、パッケージリポジトリを使用してライブラリを公開することもできます。マイクロフロントエンドチームは、ハイブリッドフレームワークを使用するモバイルアプリケーションと同様に、ビルド時にパッケージ化されたライブラリの特定のバージョンに対して開発できます。

3 番目のオプションは、プライベートパッケージレジストリを使用して、共通ライブラリのビルドタイム統合をサポートすることです。これにより、ライブラリ契約の変更が実行時にエラーを開始するリスクが軽減されます。ただし、このより保守的なアプローチでは、すべてのマイクロフロントエンドを新しいライブラリバージョンと同期させるためのガバナンスを強化する必要があります。

ページのロード時間を短縮するために、マイクロフロントエンドは Amazon CloudFront などの CDN からキャッシュされたチャンクからロードするライブラリの依存関係を外部化できます。

ランタイムの依存関係を管理するために、マイクロフロントエンドはインポートマップ (または などのライブラリSystem.js) を使用して、実行時に各モジュールがどこからロードされるかを指定できます。webpack Module Federation は、リモートモジュールのホストバージョンをポイントし、独立したマイクロフロントエンド間で一般的な依存関係を解決するもう 1 つのアプローチです。

もう 1 つの方法は、検出エンドポイントへの初期リクエストを使用してインポートマップの動的ロードを容易にすることです。

共有状態

マイクロフロントエンドの結合を減らすには、モノリシックアーキテクチャと同様に、同じビュー内のすべてのマイクロフロントエンドからアクセス可能なグローバル状態管理を避けることが重要です。例えば、グローバル Redux ストアをすべてのマイクロフロントエンドからアクセスできるようにすると、結合が増加します。

共有状態を排除するパターンは、マイクロフロントエンド内にカプセル化し、前述のように非同期メッセージと通信することです。

絶対に必要な場合は、グローバル状態に明確に定義されたインターフェイスを導入し、予期しない動作を避けるために読み取り専用共有をオプトインします。

マイクロフロントエンド間で複数の情報を共有する必要がある場合は、マイクロフロントエンドの境界を再検討することをお勧めします。共有の必要性は、ビジネスの進化や初期設計が不十分であることが原因である可能性があります。

また、各マイクロフロントエンドがセッション識別子を使用して必要なデータを取得するサーバー側のセッションを使用することもできます。結合を減らすには、共有状態を排除し、マイクロフロントエンド固有のセッションデータを分離することが重要です。