Solicitudes de proxy

La función de proxy de Managed Runtime le permite enrutar solicitudes a API alojadas en diferentes dominios a través del mismo dominio que su escaparate.
Diagrama asociado

¿Por qué utilizar el mismo dominio que su escaparate? Imagine que su escaparate está alojado en www.northerntrailoutfitters.com y desea solicitar la API de B2C Commerce a . api.commercecloud.salesforce.com Realizar esta solicitud sin una conexión proxy implica pasos adicionales de configuración y no es tan rápido y observable como podría serlo con la conexión proxy. Comparemos los dos enfoques:

Sin conexión proxyCon conexión proxy
Debe configurar el servidor de la API para que responda con encabezados de intercambio de recursos entre orígenes (CORS).No se requiere ninguna configuración adicional para el CORS.
Las solicitudes a la API requieren una solicitud adicional previa al envío, lo que ralentiza el rendimiento.No se han realizado solicitudes de red adicionales.
Si el servidor de la API no almacena las respuestas en caché, se pierde la oportunidad de aumentar el rendimiento de forma significativa.Puede ordenar a la CDN de Managed Runtime que almacene en caché solicitudes específicas.
Si no tiene acceso a los registros del servidor de la API, es difícil medir cómo afecta al rendimiento general.Todas las solicitudes a la API que se enrutan a través de la CDN de Managed Runtime mediante una conexión de proxy quedan registradas.

Ahora que entiende el valor de usar proxies, vamos a explorar los diferentes métodos para configurarlos.

Durante el desarrollo local, los proxies se pueden configurar editando la mobify.ssrParameters.proxyConfigs matriz en <PROJECT_DIR>/config/default.js. Por ejemplo, para configurar un proxy para la API de B2C Commerce:

El conjunto proxyConfigs contiene objetos que definen una configuración de proxy con las siguientes propiedades:

  • host: el host de origen que recibe sus solicitudes.
  • path: el nombre utilizado en la ruta de acceso de la solicitud para identificar este proxy.

Para realizar una solicitud de proxy en el código de la aplicación, siga este patrón al crear rutas de acceso de solicitud: /mobify/proxy/<PROXY_PATH>.

Elija rutas de proxy que faciliten el reconocimiento de las API que está usando.

Veamos un ejemplo de solicitud que utiliza api como el valor path. Por defecto, los proyectos creados con PWA Kit incluyen una configuración de proxy que asocia la api ruta con la API de B2C Commerce.

Cuando cambia la configuración del proxy durante el desarrollo local, debe reiniciar el servidor de desarrollo local para que los cambios surtan efecto.

Managed Runtime ignora la configuración del proxy en los archivos de configuración. En su lugar, los proxies deben configurarse mediante Runtime Admin o Managed Runtime API.

Para configurar los proxies para un entorno de Managed Runtime utilizando nuestra herramienta de administración basada en la web, siga estos pasos:

  1. Inicie sesión en la herramienta Runtime Admin.
  2. Haga clic en su proyecto.
  3. Haga clic en un entorno.
  4. Haga clic en Configuración de entorno desde el menú izquierdo de navegación.
  5. En la sección Avanzada, haga clic en Editar.
  6. En Configuraciones de proxy, haga clic en Agregar un nuevo proxy.
  7. Escriba la ruta, el protocolo y el host.
  8. Repita estos pasos para hasta 8 configuraciones de proxy.
  9. Vuelva al inicio de la sección Avanzada y haga clic en Actualizar.
  10. Espere a que el paquete termine de reimplementarse.
  11. Verifique que la configuración del proxy funcione como debería.

Captura de Runtime Admin

También puede configurar proxies para entornos de Managed Runtime mediante programación mediante el punto de projects_target_partial_update conexión. La Managed Runtime API con frecuencia usa el término “objetivo” en lugar de “entorno”, pero ambos términos se refieren a lo mismo.

Este es un ejemplo de solicitud que actualiza un entorno para incluir una configuración de proxy para la ruta api y ocapi:

Al crear o actualizar entornos, el cuerpo de la solicitud JSON acepta una matriz de objetos de configuración de proxy de un campo llamado ssr_proxy_configs. Los objetos de configuración de proxy incluyen host y path, como en los archivos deconfiguración.

Para evitar el tiempo de inactividad, los pasos para añadir o eliminar proxies en un entorno de producción deben realizarse en un orden específico.

Para agregar una conexión de proxy a un entorno de producción, haga lo siguiente:

  1. Edite la configuración del entorno para el entorno de producción utilizando Runtime Admin o la Managed Runtime API. (Siga las instrucciones descritas anteriormente).
  2. Añada la nueva conexión de proxy a la configuración del entorno y guarde los cambios.
  3. Actualice el código de su PWA Kit para utilizar el nuevo proxy.
  4. Envíe un nuevo paquete de su código del PWA Kit a Managed Runtime.
  5. Implemente el nuevo paquete.

Para eliminar un proxy de un entorno de producción, haga lo siguiente:

  1. Actualice el código de su PWA Kit para utilizar el nuevo proxy.
  2. Envíe un nuevo paquete de su código del PWA Kit a Managed Runtime.
  3. Implemente el nuevo paquete.
  4. Edite la configuración del entorno para el entorno de producción utilizando Runtime Admin o Managed Runtime API. (Siga las instrucciones descritas anteriormente).
  5. Elimine la nueva conexión de proxy de la configuración del entorno y guarde los cambios.

En el desarrollo local, puede anular las configuraciones de proxy mediante variables de entorno.

Establezca una variable de entorno llamada SSR_PROXY1 para anular el primer elemento del grupo proxyConfigs y configure otra llamada SSR_PROXY2 para reemplazar el segundo elemento, y así sucesivamente.

Esto funciona de la siguiente manera: Si la variable de entorno SSR_PROXY1 se establece en https://api-staging.example.com/api, sustituye al primer elemento del grupo proxyConfigs por el siguiente objeto de configuración del proxy:

productoEstas variables de entorno se utilizan comúnmente con el comando npm start durante el desarrollo local para utilizar diferentes instancias del host de la API, como staging o production. Este es un ejemplo que reemplaza el primer objeto de configuración del proxy para que la ruta api dirija las peticiones a una instancia de staging:

Una vez configurados los ajustes del proxy, puede buscarlos utilizando la función de utilidad getProxyConfigs del SDK de PWA Kit React. Por ejemplo, puede utilizar un código de identificación de cliente diferente, dependiendo del entorno en el que se ejecute su código:

Cuando una solicitud es proxy, tanto la solicitud al origen como la respuesta del origen se modifican para que funcionen de forma transparente con el código de la aplicación.

Los ejemplos proporcionados en esta sección asumen que la aplicación se aloja en www.northerntrailoutfitters.com y que está configurada para hacer solicitudes al proxy en api.commercecloud.com.

Antes de enviarla al host, se aplican las siguientes modificaciones a la solicitud:

  • Elimine el prefijo /mobify/proxy/<PROXY_PATH>/.
  • Agregue un encabezado de HTTP de X-Mobify: true.

Las solicitudes proxy reenvían todos los parámetros y encabezados de la cadena de consulta, incluidas las cookies.

Las siguientes modificaciones se aplican a la respuesta antes de enviarla al cliente:

  • Agregue un encabezado HTTP de X-Request-Url: <URL> con la URL que se solicitó.
  • Si la respuesta es una redirección y el encabezado de Location de la respuesta cuyo host coincide con el host del proxy, se antepone /mobify/proxy/<PROXY_PATH>/ al host.
  • Si la respuesta contiene encabezados Set-Cookie cuyo domain coincide con el host del proxy, se actualizan para que coincidan. Por ejemplo, Set-Cookie: key=val; domain=api.commercecloud.com se actualiza a Set-Cookie: key=val; domain=www.northerntrailoutfitters.com.
  • Si la respuesta contiene un encabezado Access-Control-Allow-Origin cuyo valor coincide con el del host del proxy, se actualiza a Access-Control-Allow-Origin: https://www.northerntrailoutfitters.com.

Para probar sus modificaciones, configure un proxy con httpbin.org como host. Cuando se hace una solicitud a través de ese proxy, éste se devuelve todos los encabezados que recibe.

Por defecto, la CDN no almacena las solicitudes al proxy en la caché. Este valor predeterminado permite utilizar las solicitudes de los proxies de forma transparente en su código, sin tener que preocuparse de almacenar incorrectamente las respuestas en el almacenamiento en caché.

Cuando desee que una solicitud enviada al proxy sea almacenada en la caché por la CDN, cambie el prefijo de la ruta de la solicitud de proxy a caching.

Los proxies de almacenamiento en caché no son adecuados para su uso con la API de B2C Commerce. En su lugar, use su función de almacenamiento en caché de nivel web del lado del servidor.

Las solicitudes al proxy almacenadas en la caché se diferencian de las solicitudes de proxy estándar en lo siguiente:

  • Se elimina el encabezado de HTTP Cookie.

Las respuestas almacenadas en la caché se diferencian de las respuestas estándar en lo siguiente:

  • Cualquier encabezado de HTTP Set-Cookie se elimina.

Las respuestas almacenadas en la caché incluyen los siguientes encabezados de HTTP para que cuando los valores de estas cabeceras varíen, las respuestas se almacenen en caché por separado:

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

Las respuestas que incluyen otros encabezados de HTTP no se almacenan en la caché por separado cuando sus valores varían.

Las conexiones de proxy tienen restricciones diferentes a las del servidor de aplicaciones.

  • El tiempo de ejecución para las solicitudes de proxy se limita a 30 segundos. Si no se obtiene una respuesta del origen en este tiempo, se devuelve un error HTTP 504.
  • El origen debe proporcionar un certificado válido y admitir el uso de TLS 1.2 o superior, de lo contrario, se devuelve un HTTP 502 . Puede comprobar si sus orígenes son compatibles con TLS utilizando la herramienta SSL Labs .
  • Los tamaños de la solicitud o respuesta no tienen límite.
  • Las solicitudes conectadas al proxy pueden utilizar el encabezado Cookie. Las respuestas conectadas al proxy pueden incluir el encabezado Set-Cookie.
  • El host conectado al proxy debe ser públicamente accesible. Si solo se puede acceder al host proxy desde una red privada o está bloqueado como demandware.net hosts, se devolverá un error HTTP.
  • El proxy de almacenamiento en caché solo admite HEAD, GET y OPTIONS métodos. POST No se admiten solicitudes.

Ahora que entiende cómo y por qué usar proxies en su aplicación de comercio, continúe explorando la Documentación de PWA Kit.