Strumieniowy backend utrzymuje otwarte połączenie i przesyła dane partiami: na przykład SSE może wysyłać tekst odpowiedzi modelu w miarę jej generowania, a WebSocket umożliwia dwukierunkową komunikację. 22 października 2026 r. Google ogłosiło publiczną wersję zapoznawczą strumieniowania w Cloud API Gateway. Brama może przekazywać takie odpowiedzi i stosować do żądań standardowe reguły uwierzytelniania oraz narzędzia monitorowania; do testów trzeba utworzyć nową bramę z włączonym trybem strumieniowym.

W ogłoszeniu Google wymieniono SSE, strumieniowe odpowiedzi HTTP i kodowanie transferu chunked, WebSockets oraz serwerowe i dwukierunkowe strumieniowanie gRPC. Odpowiedzi HTTP są przekazywane klientowi w miarę napływania z backendu, także w formacie NDJSON. Dzięki temu trasy strumieniowe mogą pozostać za tą samą bramą API Gateway, która obsługuje już zwykłe żądania.
Co zmienia się w API i infrastrukturze
Operacje strumieniowe nie wymagają osobnego opisu API ani specjalnych rozszerzeń specyfikacji. W wersji zapoznawczej tryb strumieniowy ustawia się podczas tworzenia bramy za pomocą flagi --enable-streaming. Google informuje, że nadal dostępne są kontrole kluczy API i JWT, uwierzytelnianie backendu przy użyciu konta usługi, routing oraz integracja z Cloud Logging i Cloud Monitoring.
Wersja zapoznawcza wprowadza również przewidywalną nazwę hosta opartą na identyfikatorze bramy, numerze projektu i regionie. Przykładowy format adresu to GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Można go wcześniej umieścić w konfiguracji klienta lub CI. Ponowne utworzenie bramy z tym samym identyfikatorem, projektem i regionem zachowuje ten adres.
Testowanie bez przełączania ruchu produkcyjnego
- Wybierz istniejący backend. Zacznij od endpointu, który już wysyła SSE lub strumieniową odpowiedź HTTP. Dzięki temu łatwiej oddzielić zachowanie bramy od zmian w aplikacji.
- Utwórz osobną bramę. Tryb strumieniowy włącza się podczas tworzenia; nie można zmienić trybu istniejącej bramy. Użyj testowego identyfikatora i odpowiedniego regionu.
- Skonfiguruj limit czasu backendu. W przypadku SSE i strumieniowania HTTP domyślny czas żądania wynosi 15 sekund; strumień zostaje zamknięty po upływie ustawionego limitu. W konfiguracji OpenAPI ustaw dla backendu parametr
deadlineodpowiedni do danego scenariusza: dokumentacja dopuszcza dla bramy strumieniowej wartość do 3600 sekund. Uwzględnij też własny timeout backendu — na przykład Cloud Run może zamknąć połączenie wcześniej. - Sprawdź protokół backendu. gRPC wymaga HTTP/2 (
h2), a WebSockets — HTTP/1.1. SSE i strumieniowanie HTTP działają z HTTP/1.1 lub HTTP/2; Google zaleca HTTP/2 w tych scenariuszach. - Sprawdź, czy dane docierają. Upewnij się, że klient otrzymuje pierwsze zdarzenia przed zakończeniem całej odpowiedzi. W przypadku WebSocket sprawdź komunikację w obu kierunkach i zaplanuj ponowne łączenie klientów po zakończeniu połączenia.
- Zweryfikuj zasady i metryki. Sprawdź uwierzytelnianie, logi i limity żądań na trasie strumieniowej. Metryka request latency obejmuje pełny czas trwania strumienia, dlatego osobno mierz po stronie klienta czas do pierwszego zdarzenia i odstępy między zdarzeniami.
W przypadku WebSockets i gRPC domyślny limit czasu bez wymiany wiadomości wynosi 300 sekund; dla WebSocket nie stosuje się limitu krótszego niż 300 sekund, a połączenie i tak zostaje zakończone najpóźniej po 3600 sekundach. W przypadku SSE i strumieniowego HTTP obowiązuje ustawiony limit czasu rzeczywistego (wall-clock deadline). Dlatego długi czas request latency sam w sobie nie pokazuje, jak szybko użytkownik zobaczył pierwszy fragment.
Ograniczenia publicznej wersji zapoznawczej
W chwili uruchomienia trybu strumieniowego nie można włączyć w Cloud Console ani Terraform. Bramy z włączonym strumieniowaniem nie są też zgodne z HTTP(S) Load Balancing i Serverless NEG, więc niestandardowe domeny zależne od tego rozwiązania są niedostępne. Google wymienia te funkcje jako planowane rozszerzenia okresu wersji zapoznawczej. Przed zaplanowaniem routingu produkcyjnego i automatyzacji sprawdź dokumentację konfiguracji strumieniowania.
Praktyczny pierwszy krok to skierowanie nowej bramy do istniejącego strumieniowego backendu, jawne ustawienie limitu czasu i porównanie bezpośredniego połączenia z trasą przez bramę. Zespół sprawdzi w ten sposób zgodność protokołu, uwierzytelnianie i rzeczywisty czas do pierwszego zdarzenia bez zmiany kontraktu API ani ruchu produkcyjnego.