Google Cloud API Gateway přidává streamování: co ověřit před migrací

Streamovací backend udržuje spojení otevřené a předává data po částech: SSE může například odesílat text odpovědi modelu průběžně během generování, zatímco WebSocket umožňuje obousměrnou komunikaci. Google 22. října 2026 oznámil veřejnou verzi Preview streamování v Cloud API Gateway. Brána může takové odpovědi předávat a u požadavků uplatňovat obvyklá pravidla ověřování i nástroje pro pozorovatelnost; pro testování bude potřeba vytvořit novou bránu se zapnutým streamováním.

Oznámení Googlu uvádí SSE, streamování odpovědí HTTP a kódování chunked transfer, WebSockets i serverové a obousměrné streamování gRPC. Odpovědi HTTP se předávají klientovi průběžně, jak přicházejí z backendu, včetně NDJSON. Streamovací trasy tak mohou zůstat za stejnou bránou API Gateway, která již obsluhuje běžné požadavky.

Co se mění v API a infrastruktuře

Streamovací operace nevyžadují samostatný popis API ani speciální rozšíření specifikace. Ve verzi Preview se streamovací režim nastavuje při vytváření brány pomocí příznaku --enable-streaming. Google uvádí, že zůstávají zachovány kontroly API key a JWT, ověřování backendu pomocí service account, směrování i integrace s Cloud Logging a Cloud Monitoring.

Preview přináší také předvídatelný název hostitele založený na ID brány, čísle projektu a regionu. Příklad formátu adresy: GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Lze jej předem vložit do konfigurace klienta nebo CI. Opětovné vytvoření brány se stejným ID, projektem a regionem zachová tutéž adresu.

Testování bez přesměrování produkčního provozu

1. Vyberte existující backend. Začněte endpointem, který již odesílá SSE nebo streamovanou odpověď HTTP. Snáze tak odlišíte chování brány od změn aplikace.
2. Vytvořte samostatnou bránu. Streamování se zapíná při vytváření; režim existující brány změnit nelze. Použijte testovací ID a vhodný region.
3. Nastavte lhůtu backendu. Výchozí doba požadavku pro SSE a streamování HTTP je 15 sekund; po uplynutí nastavené lhůty se stream uzavře. V konfiguraci OpenAPI nastavte pro backend deadline odpovídající vašemu scénáři: dokumentace pro streamovací bránu připouští hodnotu až 3600 sekund. Zohledněte také vlastní timeout backendu — například Cloud Run může spojení uzavřít dříve.
4. Ověřte protokol backendu. gRPC vyžaduje HTTP/2 (h2), WebSockets HTTP/1.1. SSE a streamování HTTP fungují přes HTTP/1.1 i HTTP/2; Google pro tyto scénáře doporučuje HTTP/2.
5. Ověřte doručování dat. Zkontrolujte, že klient dostává první události ještě před dokončením celé odpovědi. U WebSocketu otestujte komunikaci oběma směry a promyslete opětovné připojení klientů po ukončení spojení.
6. Zkontrolujte zásady a metriky. Ověřte ověřování, protokoly a omezení požadavků na streamovací trase. Metrika latence požadavku měří celou dobu trvání streamu, proto na klientovi měřte zvlášť čas do první události a intervaly mezi událostmi.

Pro WebSockets a gRPC dokumentace stanoví výchozí interval bez zpráv 300 sekund; u WebSocketu se doba kratší než 300 sekund nepoužije a spojení v každém případě skončí nejpozději po 3600 sekundách. Pro SSE a streamování HTTP platí nastavený limit celkové doby. Dlouhá hodnota metriky latence požadavku proto sama o sobě neukazuje, jak rychle uživatel uviděl první část odpovědi.

Omezení veřejné verze Preview

Při spuštění nelze streamovací režim zapnout prostřednictvím Cloud Console ani Terraformu. Brány se zapnutým streamováním navíc nejsou kompatibilní s HTTP(S) Load Balancing a Serverless NEG, takže vlastní domény závislé na tomto řešení nejsou dostupné. Google tyto možnosti uvádí jako budoucí rozšíření během období Preview. Před plánováním směrování do produkce a automatizace si ověřte dokumentaci ke konfiguraci streamování.

Prvním praktickým krokem je nasměrovat novou bránu na existující streamovací backend, výslovně nastavit deadline a porovnat přímé připojení s trasou přes bránu. Tým tak ověří kompatibilitu protokolu, ověřování i skutečný čas do první události, aniž by měnil kontrakt API nebo produkční provoz.