翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# でのマイクロフロントエンドの理解と実装 AWS
*Amazon Web Services* ([寄稿者](contributors.md))
*2024 年 7 月* ([ドキュメント履歴](doc-history.md))
組織が俊敏性とスケーラビリティを求めるにつれて、従来のモノリシックアーキテクチャがボトルネックになり、迅速な開発とデプロイが妨げられることがよくあります。マイクロフロントエンドは、複雑なユーザーインターフェイスを、自律的に開発、テスト、デプロイできるより小さな独立したコンポーネントに分割することで、これを軽減します。このアプローチにより、開発チームの効率が向上し、バックエンドとフロントエンド間のコラボレーションが容易になり、分散システムのend-to-endの連携が促進されます。
この規範的なガイダンスは、さまざまなプロフェッショナルドメインの IT リーダー、製品所有者、アーキテクトがマイクロフロントエンドアーキテクチャを理解し、アマゾン ウェブ サービス () でマイクロフロントエンドアプリケーションを構築できるように作成されていますAWS。
## 概要:
マイクロフロントエンドは、アプリケーションフロントエンドを独立して開発およびデプロイされたアーティファクトに分解するために構築されたアーキテクチャです。大きなフロントエンドを自律的なソフトウェアアーティファクトに分割すると、ビジネスロジックをカプセル化し、依存関係を減らすことができます。これにより、製品増分をより迅速かつ頻繁に配信できます。
マイクロフロントエンドは*マイクロサービスに似ています*。実際、マイクロフロントエンドという用語はマイクロサービスという用語から派生しており、マイクロサービスの概念をフロントエンドとして伝えることを目的としています。マイクロサービスアーキテクチャは通常、バックエンドの分散システムとモノリシックフロントエンドを組み合わせますが、マイクロフロントエンドは自己完結型の分散フロントエンドサービスです。これらのサービスは、次の 2 つの方法で設定できます。
+ フロントエンドのみ、 がマイクロサービスアーキテクチャを実行する共有 API レイヤーと統合
+ フルスタック、つまり各マイクロフロントエンドには独自のバックエンド実装があります。
次の図は、API ゲートウェイを使用してバックエンドマイクロサービスに接続するフロントエンドモノリスを備えた従来のマイクロサービスアーキテクチャを示しています。
次の図は、マイクロサービスの実装が異なるマイクロフロントエンドアーキテクチャを示しています。
前の図に示すように、クライアント側のレンダリングまたはサーバー側のレンダリングアーキテクチャでマイクロフロントエンドを使用できます。
+ クライアント側でレンダリングされたマイクロフロントエンドは、一元化APIs Gateway によって公開された API を直接使用できます。
+ チームは、境界コンテキスト内にbackend-for-frontend (BFF) を作成して、APIs に対するフロントエンドの混雑を軽減できます。
+ サーバー側では、マイクロフロントエンドは、ハイドレーションと呼ばれる手法を使用してクライアント側で拡張されたサーバー側のアプローチで表現できます。ブラウザによってページがレンダリングされると、関連する JavaScript がハイドレートされ、ボタンのクリックなどの UI 要素とのやり取りが可能になります。
+ マイクロフロントエンドはバックエンドでレンダリングでき、ハイパーリンクを使用してウェブサイトの新しい部分にルーティングできます。
マイクロフロントエンドは、以下を実行する組織に最適です。
+ 同じプロジェクトに取り組む複数のチームでスケールします。
+ 意思決定の分散を受け入れ、デベロッパーが特定されたシステム境界内でイノベーションできるようにします。
このアプローチにより、チームの認知負荷が大幅に軽減されます。これは、チームがシステムの特定の部分を担当するためです。残りの部分を中断することなくシステムの一部に変更を加えることができるため、ビジネスの俊敏性が向上します。
マイクロフロントエンドは、個別のアーキテクチャアプローチです。マイクロフロントエンドを構築するにはさまざまな方法がありますが、それらにはすべて共通の特性があります。
+ マイクロフロントエンドアーキテクチャは、複数の独立した要素で構成されています。この構造は、バックエンドのマイクロサービスで発生するモジュール化に似ています。
+ マイクロフロントエンドは、以下で構成される境界コンテキスト内のフロントエンド実装に完全に責任を負います。
+ [ユーザーインターフェイス]
+ データ
+ 状態またはセッション
+ ビジネスロジック
+ フロー
境界コンテキストは、入出力を仲介する慎重に設計された境界を持つ内部整合性のあるシステムです。マイクロフロントエンドは、ビジネスロジックやデータをできるだけ他のマイクロフロントエンドと共有しないでください。共有が必要な場所では、カスタムイベントやリアクティブストリームなどの明確に定義されたインターフェイスを介して行われます。ただし、設計システムやログ記録ライブラリなど、クロスカットに関する懸念がある場合は、意図的に共有することをお勧めします。
推奨されるパターンは、クロスファンクショナルチームを使用してマイクロフロントエンドを構築することです。つまり、各マイクロフロントエンドは、バックエンドからフロントエンドまで作業する同じチームによって開発されます。コーディングから本番環境でのシステムの運用化まで、チームの所有権は重要です。
このガイダンスは、特定のアプローチを推奨するものではありません。代わりに、さまざまなパターン、ベストプラクティス、トレードオフ、アーキテクチャと組織の考慮事項について説明します。