Google Cloud API Gateway får strømming: Dette bør du sjekke før migrering

En strømmende backend holder tilkoblingen åpen og sender data i deler: SSE kan for eksempel sende tekst fra et modellresultat etter hvert som det genereres, mens WebSocket kan håndtere toveis kommunikasjon. 22. oktober 2026 kunngjorde Google en offentlig forhåndsversjon av strømming i Cloud API Gateway. Gatewayen kan videreformidle slike svar og bruke de vanlige reglene for autentisering og observabilitet på forespørsler. For å teste funksjonen må du opprette en ny gateway med strømmemodus aktivert.

Googles kunngjøring lister opp SSE, strømming av HTTP-svar og chunked transfer encoding, WebSockets samt serverstrømming og toveis strømming med gRPC. HTTP-svar sendes til klienten etter hvert som de kommer fra backend, inkludert NDJSON. Dermed kan strømmende ruter bruke den samme API Gateway som allerede håndterer vanlige forespørsler.

Hva endres i API-et og infrastrukturen

Strømming krever verken en egen API-beskrivelse eller spesielle utvidelser i spesifikasjonen. I forhåndsversjonen aktiveres strømmemodus når gatewayen opprettes, med flagget --enable-streaming. Google opplyser at kontroll av API-nøkkel og JWT, backend-autentisering med service account, ruting og integrasjon med Cloud Logging og Cloud Monitoring beholdes.

Forhåndsversjonen introduserer også et forutsigbart vertsnavn basert på gatewayens ID, prosjektnummeret og regionen. Adresseformatet er for eksempel GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Du kan legge det inn på forhånd i klient- eller CI-konfigurasjonen. Hvis gatewayen opprettes på nytt med samme ID, prosjekt og region, beholder den adressen.

Test uten å flytte produksjonstrafikk

1. Velg en eksisterende backend. Begynn med et endepunkt som allerede sender SSE eller et strømmende HTTP-svar. Da kan du skille gatewayens virkemåte fra eventuelle endringer i applikasjonen.
2. Opprett en separat gateway. Strømming aktiveres når gatewayen opprettes, og modusen kan ikke endres for en eksisterende gateway. Bruk en test-ID og en passende region.
3. Konfigurer backend-fristen. Standard tidsavbrudd for SSE og strømming av HTTP er 15 sekunder; strømmen lukkes når den angitte fristen utløper. Angi en passende deadline for backend i OpenAPI-konfigurasjonen. For en strømmende gateway tillater dokumentasjonen en verdi på opptil 3600 sekunder. Ta også hensyn til backendens eget tidsavbrudd – Cloud Run kan for eksempel lukke tilkoblingen tidligere.
4. Kontroller backend-protokollen. gRPC krever HTTP/2 (h2), mens WebSockets krever HTTP/1.1. SSE og strømming av HTTP fungerer med HTTP/1.1 eller HTTP/2; Google anbefaler HTTP/2 for disse bruksområdene.
5. Kontroller at dataene kommer frem. Bekreft at klienten mottar de første hendelsene før hele svaret er ferdig. For WebSocket tester du kommunikasjon i begge retninger, og planlegger hvordan klienter skal koble seg til på nytt når tilkoblingen avsluttes.
6. Kontroller policyer og målinger. Test autentisering, logger og forespørselsbegrensninger på den strømmende ruten. Målingen request latency dekker hele strømmens varighet. Mål derfor separat tiden frem til første hendelse og intervallene mellom hendelser på klienten.

For WebSockets og gRPC er standardintervallet uten meldinger 300 sekunder. For WebSocket brukes ikke en frist på under 300 sekunder, og tilkoblingen avsluttes uansett senest etter 3600 sekunder. SSE og strømmende HTTP følger den angitte wall-clock-fristen. En lang request latency-graf viser derfor ikke i seg selv hvor raskt brukeren fikk se den første delen.

Begrensninger i den offentlige forhåndsversjonen

Ved lanseringen kan strømmemodus ikke aktiveres via Cloud Console eller Terraform. Gatewayer med aktivert strømming er heller ikke kompatible med HTTP(S) Load Balancing og Serverless NEG, så egendefinerte domener som er avhengige av denne løsningen, er ikke tilgjengelige. Google omtaler disse funksjonene som mulige tillegg senere i forhåndsversjonen. Før du planlegger ruting til produksjon og automatisering, bør du sjekke dokumentasjonen for konfigurering av strømming.

Et praktisk første steg er å rette en ny gateway mot en eksisterende strømmende backend, angi en tydelig deadline og sammenligne direkte tilkobling med trafikk via gatewayen. Slik kan teamet teste protokollkompatibilitet, autentisering og faktisk tid til første hendelse uten å endre API-kontrakten eller produksjonstrafikken.