Google API Gateway wprowadza obsługę strumieniowania dla ruchu czasu rzeczywistego i AI
W skrócie: Google ogłosił publiczną wersję zapoznawczą (Public Preview) obsługi strumieniowania w API Gateway, obejmującą Server-Sent Events, odpowiedzi chunked/NDJSON, WebSockets oraz strumieniowanie gRPC. Endpointy strumieniujące mogą teraz działać za tą samą bramką co zwykłe API, zachowując dotychczasowe uwierzytelnianie, logowanie i monitorowanie, bez zmian w specyfikacji API. Połączenia mogą pozostawać otwarte do godziny, a bramki otrzymują teraz przewidywalną domyślną nazwę hosta zamiast generowanego hasha. Funkcja wiąże się też z routingiem modeli, dzięki czemu jedna bramka może strumieniować odpowiedzi z modeli Gemini, Claude i OpenAI gpt-oss.
To podsumowanie zostało automatycznie przygotowane przez sztuczną inteligencję na podstawie publikacji „Google Developers”. To nasz tekst, nie kopia oryginału — fakty, liczby i cytaty należą do źródła, do którego link znajduje się powyżej i poniżej.
Co się zmieniło?
- 1Obsługa strumieniowania (SSE, chunked/NDJSON, WebSockets, gRPC) dostępna teraz w API Gateway Public Preview
- 2Włączane flagą --enable-streaming przy tworzeniu bramki; istniejących bramek nie można przekonwertować w miejscu
- 3Połączenia mogą pozostawać otwarte do godziny; klienci powinni wdrożyć logikę ponownego łączenia
- 4Nie trzeba zmieniać istniejącej specyfikacji ani konfiguracji API, aby obsługiwać strumieniowanie
- 5Nowe bramki otrzymują deterministyczną nazwę hosta (GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev) zamiast generowanego hasha
- 6Routing modeli strumieniuje odpowiedzi z modeli Gemini, Claude i OpenAI gpt-oss hostowanych w model garden platformy Gemini
- 7Ograniczenia wersji zapoznawczej: brak domen niestandardowych przez Serverless NEG/zewnętrzny ALB, brak włączania przez konsolę Cloud, brak jeszcze obsługi Terraform; metryki opóźnień odzwierciedlają pełny czas trwania strumienia, a nie czas do pierwszego bajtu
Dlaczego to ważne?
Generowanie tokenów w czasie rzeczywistym, aktualizacje postępu agentów oraz protokoły wywoływania narzędzi MCP zależą od długotrwałych, przyrostowo dostarczanych połączeń; wcześniej zespoły musiały omijać bramkę (a wraz z nią uwierzytelnianie, limity i logowanie), aby obsłużyć strumieniowanie, tworząc niekontrolowaną ścieżkę ruchu właśnie dla obciążeń AI, które najbardziej potrzebują nadzoru.
Co to oznacza dla agentów AI i contact center?
Jeśli Twoja firma korzysta z agentów głosowych AI, pulpitów transkrypcji na żywo lub strumieniowanych potoków TTS/STT w Google Cloud, eliminuje to konieczność wyboru między użyciem bramki API do uwierzytelniania/obserwowalności a obsługą strumieniowanych odpowiedzi – warto to ocenić pod kątem routingu ruchu agentów/modeli z centralnymi limitami i monitorowaniem zamiast bezpośredniego udostępniania backendów strumieniujących.
🧪 Warte przetestowania
Warto przetestować, jeśli chcesz porównać opóźnienia strumieniowania za pośrednictwem bramki oraz zachowanie ponownego łączenia z bezpośrednimi połączeniami z backendem dla ruchu agentów głosowych lub wywoływania narzędzi MCP, ponieważ wersja Preview zmienia sposób pomiaru metryk opóźnień (pełny czas trwania strumienia) i wymaga tworzenia nowych bramek zamiast konwersji istniejących.
Źródła
- Google DevelopersOficjalneŹródło pierwotneOryginalny artykuł →„Streaming comes to API Gateway: real-time and AI-ready APIs, without changing your spec“22 paź 2026, 03:00
- Data publikacji źródła
- 22 paź 2026, 03:00
- Znalezione przez nasz system
- 22 paź 2026, 18:28
- Podsumowanie wygenerowano
- 22 paź 2026, 19:00
Artykuł napisała AI na podstawie oryginalnego źródła. Fakty, liczby i ceny pochodzą ze źródła; brakujące wartości oznaczono „Brak oficjalnych danych”. Informacje prawne, prawa autorskie i prywatność