Google Cloud API Gateway får stöd för strömning: vad du bör kontrollera före migrering

En strömmande backend håller anslutningen öppen och skickar data i delar: SSE kan till exempel skicka text från ett modellsvar medan det genereras, medan WebSocket möjliggör kommunikation i båda riktningarna. Den 22 oktober 2026 tillkännagav Google en offentlig förhandsversion av strömning i Cloud API Gateway. Gatewayen kan vidarebefordra sådana svar och tillämpa de vanliga reglerna för autentisering och observerbarhet på förfrågningar. För att testa funktionen måste du skapa en ny gateway med strömningsläget aktiverat.

I Googles tillkännagivande listas SSE, strömmande HTTP-svar och chunked transfer encoding, WebSockets samt serverbaserad och dubbelriktad gRPC-strömning. HTTP-svar skickas till klienten i takt med att de kommer från backend, även NDJSON. Det gör att strömmande sökvägar kan ligga kvar bakom samma API Gateway som redan hanterar vanliga förfrågningar.

Vad som ändras i API:t och infrastrukturen

Strömmande operationer kräver varken en separat API-beskrivning eller särskilda tillägg i specifikationen. I förhandsversionen aktiveras strömningsläget när gatewayen skapas, med flaggan --enable-streaming. Google uppger att kontroller av API-nycklar och JWT, backend-autentisering via service account, dirigering samt integrering med Cloud Logging och Cloud Monitoring finns kvar.

Förhandsversionen introducerar också ett förutsägbart värdnamn som bygger på gatewayens ID, projektnumret och regionen. Adressen har exempelvis formatet GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Du kan lägga in den i klient- eller CI-konfigurationen i förväg. Om gatewayen skapas på nytt med samma ID, projekt och region behålls adressen.

Testa utan att styra om produktionstrafiken

1. Välj en befintlig backend. Börja med en endpoint som redan skickar SSE eller ett strömmande HTTP-svar. Då kan du skilja gatewayens beteende från ändringar i applikationen.
2. Skapa en separat gateway. Strömning aktiveras när gatewayen skapas; det går inte att ändra läget för en befintlig gateway. Använd ett test-ID och en lämplig region.
3. Ställ in backendens tidsgräns. Standardtiden för SSE och strömmande HTTP är 15 sekunder; strömmen stängs när den angivna tidsgränsen löper ut. Ange ett deadline för backend i OpenAPI-konfigurationen som passar ditt scenario. För strömmande gateways tillåter dokumentationen värden på upp till 3 600 sekunder. Tänk även på backendens egen timeout – Cloud Run kan till exempel stänga anslutningen tidigare.
4. Kontrollera backendprotokollet. gRPC kräver HTTP/2 (h2) och WebSockets kräver HTTP/1.1. SSE och strömmande HTTP fungerar med HTTP/1.1 eller HTTP/2; Google rekommenderar HTTP/2 för dessa scenarier.
5. Kontrollera att data kommer fram. Se till att klienten får de första händelserna innan hela svaret är klart. För WebSocket testar du kommunikationen i båda riktningarna och planerar för att klienter kan behöva återansluta när anslutningen avslutas.
6. Kontrollera policyer och mätvärden. Verifiera autentisering, loggar och begränsningar för förfrågningar på den strömmande sökvägen. Mätvärdet för request latency speglar strömmens totala längd. Mät därför separat tiden till den första händelsen och intervallen mellan händelserna på klienten.

För WebSockets och gRPC är standardintervallet utan meddelanden 300 sekunder. För WebSocket tillämpas inte en tidsgräns under 300 sekunder, och anslutningen avslutas alltid senast efter 3 600 sekunder. För SSE och strömmande HTTP gäller den angivna tidsgränsen enligt väggklockan. Därför säger en lång request latency i sig inte hur snabbt användaren såg det första fragmentet.

Begränsningar i den offentliga förhandsversionen

Vid lanseringen går det inte att aktivera strömningsläget via Cloud Console eller Terraform. Gateways med strömning aktiverad är inte heller kompatibla med HTTP(S) Load Balancing och Serverless NEG, vilket innebär att anpassade domäner som är beroende av den här lösningen inte är tillgängliga. Google beskriver dessa funktioner som möjliga framtida tillägg under förhandsperioden. Innan du planerar produktionsdirigering och automatisering bör du kontrollera dokumentationen om hur strömning konfigureras.

Ett praktiskt första steg är att rikta en ny gateway mot en befintlig strömmande backend, uttryckligen ställa in tidsgränsen och jämföra direktanslutningen med trafiken via gatewayen. Då kan teamet testa protokollkompatibilitet, autentisering och den faktiska tiden till den första händelsen utan att ändra API-kontraktet eller produktionstrafiken.