Google Cloud API Gateway añade streaming: qué comprobar antes de migrar

Un backend de streaming mantiene abierta la conexión y transmite datos por partes: por ejemplo, SSE puede enviar el texto de respuesta de un modelo a medida que se genera, mientras que WebSocket permite la comunicación en ambas direcciones. El 22 de octubre de 2026, Google anunció la vista previa pública del streaming en Cloud API Gateway. La pasarela puede transmitir estas respuestas y aplicar a las solicitudes las reglas de autenticación habituales y las herramientas de observabilidad; para probarlo, habrá que crear una nueva pasarela con el modo de streaming habilitado.

El anuncio de Google enumera SSE, el streaming de respuestas HTTP y la codificación de transferencia fragmentada, WebSockets, además del streaming gRPC del servidor y bidireccional. Las respuestas HTTP se transmiten al cliente a medida que llegan del backend, incluido NDJSON. Así, las rutas de streaming pueden seguir detrás del mismo API Gateway que ya atiende las solicitudes normales.

Qué cambia en la API y la infraestructura

Las operaciones de streaming no requieren una descripción de API independiente ni extensiones especiales en la especificación. En la vista previa, el modo de streaming se establece al crear la pasarela mediante la marca --enable-streaming. Google indica que se mantienen las comprobaciones de API key y JWT, la autenticación del backend mediante service account, el enrutamiento y la integración con Cloud Logging y Cloud Monitoring.

La vista previa también introduce un nombre de host predecible basado en el identificador de la pasarela, el número del proyecto y la región. Por ejemplo, el formato de la dirección es GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Se puede incorporar de antemano a la configuración del cliente o de CI. Si se vuelve a crear la pasarela con el mismo identificador, proyecto y región, se conserva esa dirección.

Pruebas sin desviar el tráfico de producción

1. Elige un backend existente. Empieza con un endpoint que ya envíe SSE o una respuesta HTTP en streaming: así podrás distinguir el comportamiento de la pasarela de los cambios en la aplicación.
2. Crea una pasarela independiente. El modo de streaming se fija al crearla; no es posible cambiar el modo de una pasarela existente. Usa un identificador de prueba y una región adecuada.
3. Configura el plazo del backend. Para SSE y el streaming HTTP, el plazo de solicitud predeterminado es de 15 segundos; el flujo se cierra cuando vence el plazo establecido. En la configuración OpenAPI, define para el backend un deadline adecuado al caso: la documentación permite un valor de hasta 3600 segundos para una pasarela de streaming. Ten en cuenta también el timeout propio del backend; por ejemplo, Cloud Run puede cerrar la conexión antes.
4. Comprueba el protocolo del backend. gRPC requiere HTTP/2 (h2) y WebSockets, HTTP/1.1. SSE y el streaming HTTP funcionan con HTTP/1.1 o HTTP/2; Google recomienda HTTP/2 para estos casos.
5. Comprueba que llegan los datos. Asegúrate de que el cliente recibe los primeros eventos antes de que finalice la respuesta completa. En WebSocket, prueba la comunicación en ambas direcciones y planifica la reconexión de los clientes cuando termine la conexión.
6. Revisa las políticas y las métricas. Comprueba la autenticación, los registros y las limitaciones de solicitudes en la ruta de streaming. La métrica de latencia de las solicitudes refleja la duración total del flujo, así que mide por separado en el cliente el tiempo hasta el primer evento y los intervalos entre eventos.

Para WebSockets y gRPC, la documentación establece un intervalo predeterminado de 300 segundos sin mensajes; en WebSocket no se aplica un plazo inferior a 300 segundos y, en cualquier caso, la conexión termina como máximo a los 3600 segundos. Para SSE y el streaming HTTP se aplica el plazo de reloj de pared configurado. Por eso, una latencia elevada en el gráfico de solicitudes no indica por sí sola con qué rapidez ve el usuario el primer fragmento.

Limitaciones de la vista previa pública

En el lanzamiento, no se puede habilitar el modo de streaming desde Cloud Console ni Terraform. Además, las pasarelas con streaming habilitado no son compatibles con HTTP(S) Load Balancing ni con Serverless NEG, por lo que no están disponibles los dominios personalizados que dependen de este esquema. Google incluye estas funciones entre las posibles incorporaciones futuras durante el periodo de vista previa. Antes de planificar el enrutamiento de producción y la automatización, consulta la documentación de configuración del streaming.

Un primer paso práctico es dirigir una nueva pasarela a un backend de streaming existente, configurar explícitamente el plazo y comparar la conexión directa con la ruta que pasa por la pasarela. Así, el equipo podrá comprobar la compatibilidad del protocolo, la autenticación y el tiempo real hasta el primer evento sin modificar el contrato de la API ni el tráfico de producción.