Google Cloud API Gateway מוסיף הזרמת נתונים: מה לבדוק לפני המעבר

Backend של הזרמת נתונים משאיר חיבור פתוח ומעביר נתונים בחלקים: למשל, SSE יכול לשלוח את טקסט התשובה של המודל תוך כדי יצירתו, ואילו WebSocket יכול לקיים תקשורת דו-כיוונית. ב-22 באוקטובר 2026 הכריזה Google על תצוגה מקדימה ציבורית של הזרמת נתונים ב-Cloud API Gateway. השער יכול להעביר תגובות כאלה ולהחיל על בקשות את כללי האימות ואת כלי הניטור המוכרים; כדי לבדוק זאת יהיה צורך ליצור שער חדש כשהמצב הזורם מופעל.

בהודעת Google מפורטים SSE, הזרמת תגובות HTTP וקידוד העברה במקטעים, WebSockets, וכן הזרמת gRPC מצד השרת והזרמה דו-כיוונית. תגובות HTTP מועברות ללקוח עם הגעתן מה-backend, לרבות NDJSON. כך אפשר להשאיר נתיבים זורמים מאחורי אותו Cloud API Gateway שכבר מטפל בבקשות רגילות.

מה משתנה ב-API ובתשתית

לפעולות זורמות אין צורך בתיאור API נפרד או בהרחבות מיוחדות במפרט. בתצוגה המקדימה מגדירים מצב זרימה בעת יצירת השער באמצעות הדגל --enable-streaming. Google מציינת שבדיקות API key ו-JWT, אימות backend באמצעות service account, ניתוב ואינטגרציה עם Cloud Logging ו-Cloud Monitoring נשארים ללא שינוי.

התצוגה המקדימה מוסיפה גם שם מארח צפוי המבוסס על מזהה השער, מספר הפרויקט והאזור. לדוגמה, כתובת במבנה GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. אפשר להכניס אותה מראש לתצורת הלקוח או ה-CI. יצירה חוזרת של שער עם אותם מזהה, פרויקט ואזור משמרת את הכתובת.

בדיקה בלי להעביר את תעבורת הייצור

1. בחרו backend קיים. התחילו מנקודת קצה שכבר שולחת SSE או תגובת HTTP זורמת: כך יהיה קל להפריד בין התנהגות השער לבין שינויים באפליקציה.
2. צרו שער נפרד. הפעלת הזרימה נקבעת בזמן היצירה; אי אפשר לשנות את מצב השער הקיים. השתמשו במזהה בדיקה ובאזור מתאים.
3. הגדירו את ה-deadline של ה-backend. עבור SSE והזרמת HTTP, ברירת המחדל למשך בקשה היא 15 שניות; הזרם נסגר עם פקיעת הזמן שהוגדר. בתצורת OpenAPI הגדירו ל-backend deadline המתאים לתרחיש שלכם: תיעוד שערי ההזרמה מתיר ערך של עד 3600 שניות. הביאו בחשבון גם את ה-timeout העצמאי של ה-backend — למשל, Cloud Run עשוי לסגור את החיבור קודם.
4. בדקו את פרוטוקול ה-backend. gRPC דורש HTTP/2 (h2), ו-WebSockets דורשים HTTP/1.1. SSE והזרמת HTTP פועלים עם HTTP/1.1 או HTTP/2; Google ממליצה על HTTP/2 לתרחישים אלה.
5. בדקו שהנתונים מגיעים. ודאו שהלקוח מקבל את האירועים הראשונים לפני השלמת התשובה כולה. עבור WebSocket בדקו תקשורת בשני הכיוונים, ותכננו חיבור מחדש של לקוחות לאחר סיום החיבור.
6. בדקו מדיניות ומדדים. בדקו אימות, יומנים והגבלות בקשות בנתיב הזורם. מדד השהיית הבקשה משקף את משך הזרם כולו, ולכן מדדו בנפרד את הזמן עד לאירוע הראשון ואת המרווחים בין האירועים בצד הלקוח.

עבור WebSockets ו-gRPC, התיעוד קובע מרווח ברירת מחדל של 300 שניות ללא הודעות; ב-WebSocket לא מוחל משך קצר מ-300 שניות, ובכל מקרה החיבור מסתיים לכל המאוחר לאחר 3600 שניות. עבור SSE והזרמת HTTP חל ה-deadline שנקבע לפי זמן שעון. לכן גרף ארוך של השהיית בקשה אינו מראה לבדו כמה מהר המשתמש ראה את המקטע הראשון.

מגבלות התצוגה המקדימה הציבורית

בעת ההשקה אי אפשר להפעיל מצב זרימה דרך Cloud Console או Terraform. בנוסף, שערים שבהם הזרמת נתונים מופעלת אינם תואמים ל-HTTP(S) Load Balancing ול-Serverless NEG, ולכן דומיינים מותאמים אישית התלויים בתצורה זו אינם זמינים. Google מציינת יכולות אלה כתוספות עתידיות במהלך תקופת התצוגה המקדימה. לפני תכנון ניתוב ואוטומציה של תעבורת ייצור, עיינו בתיעוד להגדרת הזרמה.

צעד ראשון מעשי הוא להפנות שער חדש ל-backend זורם קיים, להגדיר במפורש deadline ולהשוות בין חיבור ישיר לבין ניתוב דרך השער. כך הצוות יוכל לבדוק תאימות פרוטוקול, אימות ואת הזמן בפועל עד לאירוע הראשון, בלי לשנות את חוזה ה-API או את תעבורת הייצור.