Google Cloud API Gateway prend en charge le streaming : points à vérifier avant la migration

Un backend en streaming maintient la connexion ouverte et transmet les données par fragments : par exemple, SSE peut envoyer le texte d’une réponse de modèle au fur et à mesure de sa génération, tandis qu’un WebSocket permet des échanges bidirectionnels. Le 22 octobre 2026, Google a annoncé l’aperçu public du streaming dans Cloud API Gateway. La passerelle peut transmettre ces réponses et appliquer aux requêtes les règles d’authentification et les outils d’observabilité habituels ; pour effectuer des tests, il faudra créer une nouvelle passerelle avec le mode streaming activé.

L’annonce de Google mentionne SSE, le streaming des réponses HTTP et l’encodage de transfert chunked, les WebSockets, ainsi que le streaming gRPC côté serveur et bidirectionnel. Les réponses HTTP sont transmises au client à mesure qu’elles arrivent du backend, y compris au format NDJSON. Il est ainsi possible de conserver les routes de streaming derrière la même API Gateway que celle qui traite déjà les requêtes ordinaires.

Ce qui change dans l’API et l’infrastructure

Les opérations de streaming ne nécessitent ni description d’API distincte ni extensions spécifiques dans la spécification. Dans l’aperçu, le mode streaming est défini lors de la création de la passerelle au moyen de l’indicateur --enable-streaming. Google précise que les contrôles de clé API et de JWT, l’authentification du backend par compte de service, le routage et l’intégration à Cloud Logging et Cloud Monitoring sont conservés.

L’aperçu introduit également un nom d’hôte prévisible, fondé sur l’identifiant de la passerelle, le numéro du projet et la région. Par exemple, l’adresse suit le format GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Vous pouvez l’intégrer à l’avance à la configuration du client ou à la CI. La recréation d’une passerelle avec le même identifiant, le même projet et la même région conserve cette adresse.

Tester sans rediriger le trafic de production

1. Choisissez un backend existant. Commencez par un point de terminaison qui envoie déjà des événements SSE ou une réponse HTTP en streaming : cela permettra de distinguer le comportement de la passerelle des changements apportés à l’application.
2. Créez une passerelle distincte. Le mode streaming est défini à la création ; il est impossible de modifier le mode d’une passerelle existante. Utilisez un identifiant de test et une région adaptée.
3. Configurez le délai d’expiration du backend. Pour SSE et le streaming HTTP, le délai de requête par défaut est de 15 secondes ; le flux se ferme à l’expiration du délai défini. Dans la configuration OpenAPI, définissez pour le backend un deadline adapté à votre cas d’usage : la documentation autorise une valeur allant jusqu’à 3 600 secondes pour une passerelle en streaming. Tenez également compte du délai d’expiration propre au backend — Cloud Run, par exemple, peut fermer la connexion plus tôt.
4. Vérifiez le protocole du backend. gRPC exige HTTP/2 (h2), tandis que les WebSockets nécessitent HTTP/1.1. SSE et le streaming HTTP fonctionnent avec HTTP/1.1 ou HTTP/2 ; Google recommande HTTP/2 pour ces scénarios.
5. Vérifiez la réception des données. Assurez-vous que le client reçoit les premiers événements avant la fin de la réponse complète. Pour WebSocket, testez les échanges dans les deux sens et prévoyez la reconnexion des clients après la fin de la connexion.
6. Vérifiez les règles et les métriques. Contrôlez l’authentification, les journaux et les limites de requêtes sur la route de streaming. La métrique de latence des requêtes reflète la durée totale du flux ; mesurez donc séparément côté client le temps jusqu’au premier événement et les intervalles entre les événements.

Pour WebSockets et gRPC, la documentation définit par défaut à 300 secondes l’intervalle sans message ; pour WebSocket, un délai inférieur à 300 secondes n’est pas appliqué, et la connexion prend fin dans tous les cas au plus tard après 3 600 secondes. Pour SSE et le streaming HTTP, c’est le délai total défini qui s’applique. Un graphique de latence des requêtes élevé ne permet donc pas, à lui seul, de savoir à quelle vitesse l’utilisateur a reçu le premier fragment.

Limites de l’aperçu public

Au lancement, le mode streaming ne peut pas être activé via Cloud Console ni Terraform. De plus, les passerelles en mode streaming ne sont pas compatibles avec HTTP(S) Load Balancing ni avec Serverless NEG ; les domaines personnalisés dépendant de cette configuration ne sont donc pas disponibles. Google présente ces fonctionnalités comme de futurs ajouts pendant la période d’aperçu. Avant de planifier le routage de production et l’automatisation, consultez la documentation sur la configuration du streaming.

Pour commencer concrètement, dirigez une nouvelle passerelle vers un backend en streaming existant, configurez explicitement le délai d’expiration et comparez la connexion directe à celle passant par la passerelle. L’équipe pourra ainsi vérifier la compatibilité des protocoles, l’authentification et le temps réel jusqu’au premier événement, sans modifier le contrat de l’API ni le trafic de production.