リクエストのプロキシ

Managed Runtime の CDN で提供されているプロキシサーバーを使用すると、ストアフロントと同じドメインを通じて、別のドメインでホストされている API にリクエストをルーティングできます。
関連ダイアグラム

ストアフロントと同じドメインを使用する理由を考えてみましょう。ストアフロントが www.northerntrailoutfitters.com でホストされていて、api.commercecloud.salesforce.com にリクエストを行ってコマースデータを取得したいとしましょう。プロキシなしでこのリクエストを行うには、余分な構成の手順を行わなければならず、プロキシを使用する場合ほどすばやく、観察が可能なものではありません。2 つのアプローチを比較してみましょう。

プロキシを使用しない場合プロキシを使用した場合
Cross-Origin Resource Sharing (クロスオリジンリソース共有) ヘッダーで応答を行うために、API サーバーを構成する必要があります。CORS のために余分な構成を行う必要はありません。
API リクエストで余分なプリフライトリクエストが必要なため、パフォーマンスが低下します。余分なネットワークリクエストは行われません。
API サーバーでレスポンスのキャッシュが行われない場合、パフォーマンスを大幅に向上させる機会を逃します。特定のリクエストをキャッシュするように Managed Runtime の CDN に指示できます。
API サーバーのログにアクセスできない場合、全体的なパフォーマンスに対する影響を測定するのが難しくなります。プロキシを使用して Managed Runtime の CDN を通じてルーティングされるすべての API リクエストはログに記録されます。

これでプロキシを使用する価値を理解したので、プロキシを構成するさまざまな方法について見てみましょう。

ローカル開発の場合、プロキシを構成する主な方法は <PROJECT_DIR>/config/default.js で mobify.ssrParameters.proxyConfigs 配列を編集することです:

proxyConfigs 配列には、以下のプロパティでプロキシ構成を定義するオブジェクトが含まれています:

  • host: リクエストを受信するホスト。ドメインとサブドメインを含みます。
  • path: プロキシをトリガーするためにリクエストパスで使用される文字列。
  • protocol: ネットワークプロトコル (http または https)。オプション (デフォルト値は https)。

アプリケーションコードでプロキシされたリクエストを行うには、リクエストパスを構築する際に、/mobify/proxy/<PROXY_PATH> のパターンを使用します。

異なるプロキシ構成が多数ある場合は、使用している API を簡単に認識できるプロキシパスを選択します。

api を <PROXY_PATH> の値として使用するリクエストの例を見てみましょう。デフォルトでは、PWA Kit で作成したすべてのプロジェクトにはデフォルトの構成があり、api パスが Salesforce Commerce API に関連づけられています。

また、このリクエストの例では、2 つのヘルパー関数を使用して API リクエストが一貫性をもって機能するようになっています:

  1. getAppOrigin、PWA Kit React SDK から、ローカル開発環境と Managed Runtime 環境の両方に対し、正しい起点を返します。
  2. fetch、cross-fetch ライブラリから、ブラウザーと Note.js でネットワークリクエストを行う場合の差異を処理します。

ローカル開発中にプロキシ構成を変更した場合は、変更が適用されるようにローカル開発サーバーを再起動する 必要があります 。

ファイル名が Managed Runtime の名前と一致しない限り、default.js のプロキシ設定と app/config の他の構成ファイルは無視されます。詳細については、環境固有の構成を参照してください。

Managed Runtime 環境のプロキシを構成するには、Runtime Admin ツールを使用する方法と、Managed Runtime API を使用する方法があります。

Runtime Admin の使用

当社の Web ベースの管理ツールを使用して Managed Runtime 環境のプロキシを構成するには、以下の手順に従います:

  1. Runtime Admin ツールにログインします。
  2. プロジェクトをクリックします。
  3. 環境をクリックします。
  4. 左のナビゲーションメニューで Environment Settings (環境設定) をクリックします。
  5. Advanced (詳細) セクションで Edit (編集) をクリックします。
  6. Proxy Configs (プロキシ構成) で Add New Proxy (新規プロキシの追加) をクリックします。
  7. パス、プロトコル、ホストを入力します。
  8. 最大 8 件のプロキシまで、この操作を繰り返します。
  9. Advanced (詳細) セクションの最初に戻り、Update (更新) をクリックします。
  10. バンドルの再デプロイが完了するまで待ちます。
  11. プロキシ構成が適切に機能していることを確認します。

Runtime Admin のスクリーンショット

Managed Runtime API の使用

Managed Runtime 環境のプロキシは、Managed Runtime API の /target エンドポイントを使用してプログラムで構成することもできます。(Managed Runtime API では、多くの場合 “environment” (環境) の代わりに “target” (ターゲット) という用語が使用されますが、いずれの用語も同じ内容を指しています。)

環境を作成または更新する場合、JSON リクエストボディは、ssr_proxy_configs というフィールドからのプロキシ構成オブジェクトの配列を受け入れます。これらのプロキシ構成オブジェクトは、構成ファイルと同様に、host、path、および protocol (オプション) の各プロパティで定義されます。

以下に、api パスのプロキシ構成を含めるように環境を更新するリクエストの例を示します:

ダウンタイムを防ぐために、Production (本番) 環境でプロキシを追加または削除する作業は特定の順番で行う必要があります。

Production (本番) 環境にプロキシを追加するには:

  1. Runtime Admin または Managed Runtime API を使用して Production (本番) 環境の環境設定を編集します。(前述の手順に従ってください。)
  2. 環境設定に新規プロキシを追加し、編集を保存します。
  3. 新しいプロキシを使用するように PWA Kit コードを更新します。
  4. PWA Kit コードの新しいバンドルを Managed Runtime にプッシュします。
  5. 新しいバンドルをデプロイします。

Production (本番) 環境からプロキシを削除するには:

  1. 新しいプロキシを使用するように PWA Kit コードを更新します。
  2. PWA Kit コードの新しいバンドルを Managed Runtime にプッシュします。
  3. 新しいバンドルをデプロイします。
  4. Runtime Admin または Managed Runtime API を使用して Production (本番) 環境の環境設定を編集します。(前述の手順に従ってください。)
  5. 環境設定から新規プロキシを削除し、編集を保存します。

環境変数を設定することで、ローカル開発のプロキシ構成を上書きできます。

proxyConfigs 配列の最初の要素を上書きするには SSR_PROXY1 という環境変数、2 番目の要素を上書きするには SSR_PROXY2 という環境変数のように、対応する環境変数を設定します。

その仕組みを説明します。環境変数 SSR_PROXY1 を https://api-staging.example.com/api に設定すると、proxyConfigs 配列の最初の要素が以下のプロキシ構成オブジェクトに置換されます:

これらの環境変数は、一般的にローカル開発で npm start コマンドとともに、API ホストの異なるインスタンス (Staging (ステージング) や Production (本番) など) を使用するために使われます。以下に示すのは、最初のプロキシ構成オブジェクトを上書きして、api パスで Staging (ステージング) インスタンスにリクエストをルーティングする例です:

プロキシ設定の構成後、PWA Kit React SDK からユーティリティ関数 getProxyConfigs を使用してプロキシ設定を検索できます。たとえば、コードが実行されている環境に応じて、以下のように異なるクライアント ID を使用できます:

リクエストがプロキシサーバーを通じてルーティングされる場合、リクエストとレスポンスは両方ともアプリケーションコードと透過性をもって機能するように変更されます。

このセクションで示す例では、アプリが www.northerntrailoutfitters.com でホストされており、かつ、リクエストを api.commercecloud.com. にプロキシするように構成されていると仮定しています。

リクエストの変更

ホストに送信される前に、以下の変更がリクエストに適用されます:

  • /mobify/proxy/<PROXY_PATH>/ 接頭辞の削除。
  • X-Mobify: true の HTTP ヘッダーの追加。

プロキシされたリクエストは、Cookie を含む、すべてのクエリ文字列パラメーターとヘッダーも転送します。

レスポンスの変更

クライアントに送信される前に、以下の変更がレスポンスに適用されます:

  • X-Request-Url: <URL> の HTTP ヘッダーの追加。URL はリクエストされた URL。
  • レスポンスがリダイレクトで、レスポンスの Location ヘッダーの host がプロキシの host と一致する場合、host の前に /mobify/proxy/<PROXY_PATH>/ が追加されます。
  • レスポンスに Set-Cookie ヘッダーが含まれており、その domain がプロキシの host と一致する場合は、一致するように更新されます。たとえば、Set-Cookie: key=val; domain=api.commercecloud.com は Set-Cookie: key=val; domain=www.northerntrailoutfitters.com のように更新されます。
  • レスポンスに Access-Control-Allow-Origin ヘッダーが含まれており、その値がプロキシの host と一致する場合は、Access-Control-Allow-Origin: https://www.northerntrailoutfitters.com に更新されます。

変更をテストするには、プロキシ構成を httpbin.org をホストとして構成します。このプロキシを通じてリクエストを行うと、受信したヘッダーがエコーバックされます。

デフォルトでは、プロキシされたリクエストは CDN でキャッシュされません。このデフォルトによって、レスポンスが誤ってキャッシュされることを心配せずに、コードでプロキシリクエストを透過的に使用できます。

プロキシされたリクエストを CDN で キャッシングしたい 場合は、リクエストで使用するパス接頭辞を proxy から caching に変更します。

キャッシングの詳細

キャッシュされたプロキシリクエストは、以下の点で標準のプロキシリクエストとは異なります:

  • Cookie HTTP ヘッダーが削除されています。

キャッシュされたレスポンスは、以下の点で標準のレスポンスとは異なります:

  • すべての Set-Cookie HTTP ヘッダーが削除されています。

キャッシュされたレスポンスには以下の HTTP ヘッダーが含まれており、これらのヘッダーの値が異なると、レスポンスは別々にキャッシュされます:

  • Accept
  • Accept-Charset
  • Accept-Encoding
  • Accept-Language
  • Authorization
  • Range

その他の HTTP ヘッダーを含むレスポンスは、値が異なる場合でも別々には キャッシュされません 。

  • プロキシされたホストでは protocol が https に設定されている場合、Transport Level Security (TLS) プロトコルのバージョン 1.2 以降を使用する必要があります。

これで、コマースアプリでプロキシを使用する理由と方法についての学習が終わりました。PWA Kit ドキュメントを参照して、理解を深めてください。