Archivos de configuración
Solicitudes de proxy
Retail React App
Renderización
Enrutamiento
Componentes especiales
Gestión de estado
Habilidades para garantizar el éxito
Ask the Community
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.

¿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 proxy | Con 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>. Por ejemplo, para configurar un proxy para la API de B2C Commerce:
1{
2 "proxyConfigs": [
3 {
4 "host": "<SHORT_CODE>.api.commercecloud.salesforce.com",
5 "path": "api"
6 }
7 ]
8}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: <PROXY_PATH>.
Elija rutas de proxy que faciliten el reconocimiento de las API que está usando.
Tip
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.
1import { getAppOrigin } from "pwa-kit-react-sdk/utils/url";
2
3// `getAppOrigin` returns the correct origin for both local development and Managed Runtime environments.
4fetch(`${getAppOrigin()}/mobify/proxy/api/categories/bikes`);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:

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:
1curl "https://cloud.mobify.com/api/projects/$PROJECT/target/$ENVIRONMENT/" \
2 --request 'PATCH' \
3 --header "Authorization: Bearer $API_KEY" \
4 --data '{
5 "ssr_proxy_configs": [
6 {
7 "host": "api.commercecloud.salesforce.com",
8 "path": "api",
9 },
10 {
11 "host": "aaaa-001.dx.commercecloud.salesforce.com",
12 "path": "ocapi"
13 }
14 ]
15 }'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:
Para eliminar un proxy de un entorno de producción, haga lo siguiente:
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:
1{
2 "host": "api-staging.example.com",
3 "path": "api"
4}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:
1SSR_PROXY1=https://api-staging.example.com/api npm startUna 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:
1import { getProxyConfigs } from "pwa-kit-react-sdk/ssr/universal/utils.js";
2
3const HOST_TO_CLIENT_ID = {
4 "api-staging.example.com": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
5 default: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
6};
7
8const CLIENT_ID = (function getClientId() {
9 const { host } = getProxyConfigs().find((c) => c.path === "api");
10 return HOST_TO_CLIENT_ID[host] || HOST_TO_CLIENT_ID["default"];
11})();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.
Note
Antes de enviarla al host, se aplican las siguientes modificaciones a la solicitud:
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:
X-Request-Url: <URL> con la URL solicitada.Location de la respuesta cuyo host coincide con el host del proxy, se antepone <PROXY_PATH> al host.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.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 sí 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.
Note
Las solicitudes al proxy almacenadas en la caché se diferencian de las solicitudes de proxy estándar en lo siguiente:
Cookie.Las respuestas almacenadas en la caché se diferencian de las respuestas estándar en lo siguiente:
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:
AcceptAccept-CharsetAccept-EncodingAccept-LanguageAuthorizationRangeLas 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.
Cookie. Las respuestas conectadas al proxy pueden incluir el encabezado Set-Cookie.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.