View a markdown version of this page

マイクロフロントエンドを使用したページとビューの作成 - 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 やプロキシでサポートされるエッジサイドインクルード (GIS) やサーバーサイドインクルード (SSI) などのトランスクルージョン手法を使用して、クライアントにワイヤ経由で送信する前にページを作成します。VoIP には以下が必要です。

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

  • VoIP および 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 フラグメントとキャッシュレイヤーをレンダリングするためのロジックが含まれています。

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