GraphQL Federation: איך מאחדים כמה שירותי Backend לגרף אחד

מאת צוות מדיה דיל · 02.09.2026 · טכנולוגיה · 6 דק׳

איך @key מחבר ישויות בין Subgraphs, למה Query Planning קריטי לביצועים, וההבדל בין Federation מודרנית ל-Schema Stitching הישנה.

סכימת GraphQL יחידה וענקית שכל צוות מוסיף אליה שדות היא פתרון שעובד מצוין עם שני צוותים ומתפרק עם עשרה. GraphQL Federation פותר את זה על ידי חלוקת הסכימה לחלקים עצמאיים (Subgraphs) שכל צוות מנהל בנפרד, כאשר Gateway מרכזי מרכיב אותם לגרף אחד אחיד כלפי הלקוח — בלי שהלקוח בכלל יידע שמאחוריו יש כמה שירותים.

הבעיה עם סכימה מונוליתית

כשכל הצוותים כותבים לתוך אותה סכימת GraphQL, כל שינוי דורש תיאום, כל דיפלוי חוצה בעלות, וקשה לדעת איזה צוות אחראי על איזה שדה. Federation מפצל את הבעלות: כל צוות מריץ Subgraph משלו עם הסכימה, הלוגיקה והדיפלוי שלו — בדיוק כמו שמיקרו-שירותים מפצלים בעלות בצד ה-Backend.

@key: איך שני Subgraphs מדברים על אותה ישות

הבעיה המרכזית ב-Federation היא ישויות (Entities) משותפות — למשל "משתמש" שגם שירות ההזמנות וגם שירות הפרופיל צריכים להרחיב. Directive ה-@key מסמן שדה מזהה (כמו id) שמאפשר ל-Subgraph אחד "להצביע" על ישות שמוגדרת בעיקרה ב-Subgraph אחר, ולהוסיף לה שדות משלו — Gateway יודע לאחד את התוצאות משני המקורות לאובייקט אחד בתשובה ללקוח.

Query Planning: פיצול שאילתה אחת לכמה קריאות שירות

כשלקוח שולח שאילתה שנוגעת בכמה Subgraphs, ה-Gateway בונה תוכנית ביצוע (Query Plan) — איזה חלק לשלוח לאיזה Subgraph, ובאיזה סדר, כשחלק מהקריאות תלויות בתוצאה של קריאות קודמות (למשל לקבל מזהה מוצר משירות אחד לפני שקוראים לשירות מלאי איתו). זו הסיבה שתכנון גבולות ה-Subgraph משפיע ישירות על מספר קריאות הרשת הפנימיות ועל Latency כולל.

N+1 בקנה מידה מפוזר

בעיית N+1 המוכרת מ-GraphQL רגיל (Dataloader לפתרון) מקבלת ממד נוסף ב-Federation: קריאה אחת מהלקוח יכולה להפוך לעשרות קריאות רשת פנימיות בין Subgraphs אם לא נעשה Batching נכון ברמת ה-Gateway. ניטור מספר הקריאות הפנימיות שכל Query חיצוני מייצר הוא חובה, לא Nice-to-have, כדי לתפוס בעיות ביצועים לפני שהן מגיעות לפרודקשן.

Schema Stitching: הגישה הישנה, ולמה היא פחות טובה

לפני Federation, הגישה הרווחת היתה Schema Stitching — מיזוג ידני של כמה סכימות לאחת. הבעיה: Stitching דורש ידע מרכזי על כל הסכימות בזמן המיזוג, מה שיוצר צוואר בקבוק דומה למונוליט. Federation הפוך: כל Subgraph מצהיר בעצמו איך הוא מתחבר לאחרים, וה-Gateway מרכיב את זה אוטומטית בלי תלות בקוד מיזוג ידני שמישהו צריך לתחזק.

ממשל סכימה: Schema Registry ובדיקת שינויים שוברים

כשכמה צוותים תורמים לגרף אחד, שינוי שדה בטעות יכול לשבור לקוחות שתלויים בו בלי שהצוות ששינה בכלל ידע. Schema Registry (כמו Apollo Studio) בודק כל שינוי מוצע מול שימוש בפועל בפרודקשן לפני שהוא מתקבל — הגנה קריטית שהופכת Federation לישים בארגון גדול בלי לשבור דברים כל שבוע.

Federation מול BFF: לא תמיד תחליף

Backend For Frontend (BFF) פותר בעיה דומה — אגירת נתונים מכמה מקורות מאחורי ממשק אחד — אבל ברמת קוד ייעודי לכל לקוח (מובייל, ווב). Federation נותן פתרון כללי יותר וגמיש יותר ללקוחות שונים בלי לכתוב BFF נפרד לכל אחד, אבל דורש שכל הצוותים יאמצו GraphQL כפרוטוקול משותף — לא תמיד ריאלי בארגון עם Backend הטרוגני.

הקבלה למה שקורה בעולם ה-AI

הרעיון המרכזי מאחורי Federation — לאחד כמה מקורות שירות עצמאיים מאחורי ממשק אחיד אחד — מופיע כמעט זהה בעולם סוכני ה-AI, שם MCP פותר בדיוק את אותה בעיה מבנית: איך מודל שפה מקבל גישה אחידה לכמה כלים ומקורות נתונים נפרדים, בלי לדעת מראש כמה כלים יש או איך כל אחד בנוי מבפנים.

בונים שכבת GraphQL עם כמה שירותי Backend ורוצים לתכנן את זה נכון מהתחלה? דברו איתנו בוואטסאפ.

תגיות: GraphQL Federation · GraphQL · Apollo Federation · API Architecture

← חזרה לבלוג · צור קשר