1

マイクロフロントエンドに関する文献を読むと、フロントエンドはさまざまなチームが開発したマイクロフロントエンドで構成されていることがよくわかります。各マイクロフロントエンドには、少なくとも 1 つのバックエンドがあります。私が見ていないのは、バックエンドが互いに通信していることです。そうですか？それらは、バックエンド間の通信がなくても完全に機能するように分離されていますか?

4

1 に答える 1

0

マイクロフロントエンドの利点:

  • チーム/ドメイン間で個別に UI コードをデプロイする機能
  • チームごとに異なるテクノロジーを使用する能力
  • そのドメインの UI コードの厳密な境界/カプセル化
  • コードベースが小さいため、ビルド、テスト、デプロイの時間が短縮されます

最適なマイクロフロントエンド アーキテクチャ:

  • 1 人のユーザーが webapp に直面していると仮定すると、次のようになります。
  • 「プラットフォーム」マイクロフロントエンドは「スケルトン」ページを提供します
  • ユーザーの観点からは、1 つのドメイン名を持つ単一のサイトです (CORS の問題を回避します)。
  • 「スケルトン」ページは、ネームスペース化されたルートに基づいて、チーム固有のフロントエンドを呼び出します。通常、このパスベースのルーティングは、イングレスまたはリバース プロキシを介して処理されます (たとえば/namespace/accounting、会計フロントエンドに移動します)。
  • フロントエンド サービス (マイクロフロントエンド) は、プレゼンテーションの問題に厳密に責任を負い、さまざまなデータの所有権を持つ他のバックエンド サービスを呼び出すことがよくあります。
  • フロントエンド サービスには、静的アセット/コンポーネントの提供と、ajax リクエストの処理/UI 固有のデータの作成の両方のためのロジックが含まれています。

概要:
通常、フロントエンド サービスは、表示目的でデータを作成するためにバックエンド サービスを呼び出す必要があります。たとえば、ユーザー データを表示する必要がある場合、そのユーザーに関する追加の詳細を取得するために、おそらく UserService または AccountService を呼び出す必要があります。フロントエンド サービスに固有のレプリケートされたデータを使用して別のデータストアを構築しようとすることはお勧めしません。

通常、フロントエンド サービスにはビジネス ロジックを含めないでください。ただし、小規模なアプリや初期のアプリでは、同じドメインの UI とビジネス ロジックの両方を処理する単一のサービスを用意することが理にかなっているという議論があります。一般に、狭すぎるサービスよりも広すぎるサービスを利用する方が害は少ないです。

ただし、マイクロサービス アーキテクチャでは、サービス間の必要な依存関係を最小限に抑えることが依然として重要です。よくある問題は、「依存関係」の地獄に陥ることです。サービス A を呼び出すと、サービス A がサービス B を呼び出す必要があり、アーキテクチャが遅く脆弱になります。フロントエンド サービスは通常、「1 層の深さ」だけのサービスを呼び出し、それらの応答を単一の表示データ/ペイロードに構成します。

最後に、フロントエンド サービス/ドメインの境界を賢く選択することが非常に重要です。多くのフロントエンド サービスがあり、そのすべてが同じバックエンド サービスを頻繁に呼び出す必要がある場合は、そうすべきではありません。単一の広範なフロントエンド サービスから始めて、境界に自信が持てるようになるにつれて、さらに細分化することをお勧めします。

于 2020-12-28T21:33:25.133 に答える