マイクロフロントエンドを使用したページとビューの作成 - AWS 規範ガイダンス

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

マイクロフロントエンドを使用したページとビューの作成

クライアント側のコンポジション、エッジ側のコンポジション、サーバー側のコンポジションを使用して、アプリケーションのビューを作成できます。構成パターンには、必要なチームスキル、耐障害性、パフォーマンス、キャッシュ動作の点で異なる特性があります。

次の図は、マイクロフロントエンドアーキテクチャのクライアント側、エッジ側、サーバー側のレイヤーで構成がどのように行われるかを示しています。

オリジン、CDN、およびクライアント側レイヤー、エッジ側レイヤー、サーバー側レイヤーにマイクロフロントエンドを持つクライアント。

クライアント側、エッジ側、サーバー側のレイヤーについては、以下のセクションで説明します。

クライアントサイドコンポジション

クライアント (ブラウザまたはモバイルウェブビュー) で、ドキュメントオブジェクトモデル (DOM) フラグメントとしてマイクロフロントエンドを動的にロードして追加します。 JavaScript や CSS ファイルなどのマイクロフロントエンドアーティファクトは、コンテンツ配信ネットワーク (CDNsからロードしてレイテンシーを短縮できます。クライアント側の構成には、以下が必要です。

  • シェルアプリケーションまたはマイクロフロントエンドフレームワークを所有および維持し、ブラウザで実行時にマイクロフロントエンドコンポーネントを検出、ロード、レンダリングできるようにするチーム

  • HTML、CSS、 などのフロントエンドテクノロジーにおける高度なスキルレベル JavaScript、およびブラウザ環境の深い理解

  • グローバル名前空間の競合を避けるためのページへの JavaScript ロード量の最適化と統制

次の図は、サーバーレスクライアント側構成の AWS アーキテクチャの例を示しています。

ウェブアプリケーションは CloudFront 、マイクロフロントエンド検出サービスと Amazon S3 に接続します。

クライアント側のコンポジションは、シェルアプリケーションを介してブラウザ環境で行われます。この図は、次の詳細を示しています。

  1. シェルアプリケーションがロードされると、Amazon CloudFront に最初のリクエストを行い、マニフェストエンドポイントを介してロードされるマイクロフロントエンドを検出します。

  2. マニフェストには、各マイクロフロントエンドに関する情報 (名前、URL、バージョン、フォールバック動作など) が含まれます。マニフェストは、マイクロフロントエンド検出サービスによって提供されます。この図では、この検出サービスは Amazon API Gateway 、 AWS Lambda 関数、および Amazon DynamoDB で表されています。シェルアプリケーションは、マニフェスト情報を使用して、特定のレイアウト内のページの作成を個々のマイクロフロントエンドにリクエストします。

  3. 各マイクロフロントエンドバンドルは、静的ファイル ( JavaScript、CSS、HTML など) で構成されます。ファイルは Amazon Simple Storage Service (Amazon S3) バケットでホストされ、 を通じて提供されます CloudFront。

  4. チームは、所有するデプロイパイプラインを使用して、新しいバージョンのマイクロフロントエンドをデプロイし、マニフェスト情報を更新できます。

エッジサイドコンポジション

オリジンサーバーの前にある一部の CDNsやプロキシでサポートされているエッジサイドインクルード (DDoS) やサーバーサイドインクルード (SSI) などの除外手法を使用して、クライアントにワイヤ経由で送信する前にページを作成します。 には以下が必要です。

  • 機能を持つ CDN、またはサーバー側のマイクロフロントエンドの前にプロキシをデプロイします。HAProxy 、Varnish、NGINX などのプロキシ実装は SSI をサポートします。

  • と SSI の実装の使用と制限を理解している。

通常、新しいアプリケーションを開始するチームは、コンポジションパターンにエッジサイドコンポジションを選択しません。ただし、このパターンは、トランスクルージョンに依存するレガシーアプリケーションのパスを提供する可能性があります。

サーバーサイドコンポジション

オリジンサーバーを使用して、エッジにキャッシュされる前にページを作成します。これは、PHP、Jakarta Server Pages (JSP)、テンプレートライブラリなどの従来のテクノロジーを使用して、マイクロフロントエンドのフラグメントを含めることでページを構成できます。サーバーで実行されている Next.js などの JavaScript フレームワークを使用して、サーバー側のレンダリング (SSR) でサーバー上のページを作成することもできます。

ページがサーバーでレンダリングされたら、CDNsにキャッシュしてレイテンシーを短縮できます。新しいバージョンのマイクロフロントエンドがデプロイされると、ページを再レンダリングし、キャッシュを更新して最新バージョンを顧客に配信する必要があります。

サーバー側の構成では、デプロイ、サーバー側のマイクロフロントエンドの検出、キャッシュ管理のパターンを確立するために、サーバー環境を深く理解する必要があります。

次の図は、サーバー側の構成を示しています。

7 ステップのサーバー側の構成。

この図には、以下のコンポーネントとプロセスが含まれています。

  1. Amazon CloudFront は、アプリケーションに一意のエントリポイントを提供します。ディストリビューションには 2 つのオリジンがあります。1 つ目は静的ファイル用、2 つ目は UI コンポーザー用です。

  2. 静的ファイルは Amazon S3バケットでホストされます。これらは、HTML テンプレートのブラウザと UI コンポーザーによって消費されます。

  3. UI コンポーザーは、 のコンテナクラスターで実行されますAWS Fargate。コンテナ化されたソリューションでは、必要に応じてストリーミング機能とマルチスレッドレンダリングを使用できます。

  4. の一機能である Parameter Store は AWS Systems Manager、基本的なマイクロフロントエンド検出システムとして使用されます。この機能は、消費するマイクロフロントエンドエンドポイントを取得するために UI コンポーザーが使用するキーバリューストアを提供します。

  5. 通知マイクロフロントエンドは、最適化された JavaScript バンドルを S3 バケットに保存します。これは、ユーザーインタラクションに反応する必要があるため、クライアントでレンダリングされます。

  6. レビューのマイクロフロントエンドは Lambda 関数によって構成され、ユーザーレビューは DynamoDB に保存されます。レビューのマイクロフロントエンドはサーバー側で完全にレンダリングされ、HTML フラグメントを出力します。

  7. 製品の詳細マイクロフロントエンドは、 を使用するローコードのマイクロフロントエンドですAWS Step Functions。Express ワークフローは同期的に呼び出すことができ、HTML フラグメントとキャッシュレイヤーをレンダリングするためのロジックが含まれています。

サーバー側の構成の詳細については、ブログ記事「サーバー側のレンダリングマイクロフロントエンド — アーキテクチャ」を参照してください。