מה זה GraphQL? הסבר פשוט + משרות פתוחות בישראל

GraphQL הוא שפת שאילתות לממשקים, שבה הלקוח מציין בדיוק אילו שדות הוא רוצה והשרת מחזיר בדיוק אותם - הכול דרך נקודת קצה אחת. הוא נועד לפתור מצב שבו לקוחות שונים צריכים חתכים שונים מאותם נתונים. בלוח HiTakeJob פתוחות כרגע 26 משרות שמזכירות REST API, 52 שמזכירות Node.js ו-54 שמזכירות TypeScript.

הבעיה שהוא בא לפתור

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

• יותר מדי נתונים: האפליקציה צריכה שם ותמונה ומקבלת אובייקט עם ארבעים שדות, מה שמכביד על רשת סלולרית.
• יותר מדי קריאות: כדי להציג מסך אחד צריך לפנות לשלושה נתיבים שונים ולחבר את התוצאות בצד הלקוח.

הפתרון המקובל בעולם REST היה להוסיף נתיבים ייעודיים לכל מסך, וזה יוצר ריבוי נתיבים שקשה לתחזק. GraphQL הופך את הכיוון: הלקוח מבקש מבנה, והשרת בונה אותו.

איך זה עובד - שלושת המושגים

מושג	מה זה
סכימה	חוזה כתוב שמגדיר את כל הטיפוסים והשדות הזמינים
שאילתה	בקשת קריאה שמציינת בדיוק אילו שדות רוצים
מוטציה	פעולה שמשנה נתונים - יצירה, עדכון, מחיקה
Resolver	הקוד בשרת שיודע להביא כל שדה בפועל

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

מה ההבדל המעשי מ-REST

	REST	GraphQL
מבנה	נתיב לכל משאב	נקודת קצה אחת
מי קובע מה חוזר	השרת	הלקוח
מטמון	מובנה ב-HTTP, פשוט	דורש עבודה בצד הלקוח
קודי שגיאה	קודי HTTP סטנדרטיים	לרוב 200 עם שדה שגיאות
גרסאות	גרסה בנתיב	הוספת שדות והוצאה משימוש בהדרגה
עקומת למידה	נמוכה	גבוהה יותר בצד השרת

שתי השורות האמצעיות הן המחיר האמיתי. אובדן המטמון הסטנדרטי של HTTP משמעותי במיוחד לאתרי תוכן, ולכן ממשקים ציבוריים נוטים להישאר בסגנון REST. ההשוואה המלאה נמצאת במה זה REST API.

איך נראית שאילתה בפועל

בלי להיכנס לתחביר, שווה להבין את המבנה: הלקוח שולח בקשה אחת שמתארת עץ - "תן לי את המשרות האחרונות, ולכל אחת את הכותרת, את שם החברה ואת העיר". התשובה חוזרת באותו מבנה בדיוק, כך שאין צורך לחפש איפה כל שדה יושב.

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

בעיית N+1 - הכשל הקלאסי

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

הפתרון המקובל הוא שכבת איסוף שממתינה רגע, אוספת את כל הבקשות לאותו סוג נתון, ומבצעת שאילתה מקובצת אחת. זהו רכיב סטנדרטי בכל מימוש רציני, ומועמד שמזכיר אותו מסמן ניסיון אמיתי.

מה נעשה מסובך יותר

• הרשאות. כשהלקוח בוחר שדות, צריך לאכוף הרשאה ברמת השדה ולא ברמת הנתיב - למשל שדה שכר שגלוי רק למגייס.
• עומס. שאילתה מקוננת עמוקה יכולה לייצר עבודה עצומה בשרת; לכן מגבילים עומק ומורכבות.
• מטמון. אין מטמון HTTP פשוט; צריך מנגנון בצד הלקוח או שכבה ייעודית.
• ניטור. כל הבקשות מגיעות לאותה נקודת קצה, ולכן מדידה לפי כתובת חסרת משמעות - צריך למדוד לפי שם השאילתה.
• קבצים. העלאת קבצים אינה חלק מהתקן ודורשת פתרון נוסף.

הסעיף השני הוא גם שיקול אבטחה: ממשק ציבורי בלי מגבלת מורכבות חשוף לשאילתה אחת שמפילה את השרת, בלי צורך בכלים מיוחדים.

מתי זה שווה את המורכבות

מתאים	פחות מתאים
כמה לקוחות עם צרכי נתונים שונים	לקוח אחד עם מסכים קבועים
מסכים שמאחדים נתונים מכמה מקורות	ממשק ציבורי לצד שלישי
אפליקציה ניידת שרגישה לנפח	אתר תוכן שנשען על מטמון
צוות עם ניסיון קודם בתחום	צוות קטן שמקים מוצר ראשון

הגישה המקובלת היום בארגונים רבים היא שילוב: ממשק בסגנון REST לשירותים פנימיים ולצד שלישי, ושכבת GraphQL מעליהם רק עבור הלקוחות שבאמת צריכים גמישות.

מה זה אומר על עבודת הצוותים

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

מה זה אומר למי שמחפש עבודה

בישראל זה מופיע בעיקר בחברות מוצר עם אפליקציה ואתר במקביל, ופחות בארגונים גדולים ובמערכות ותיקות. הוא כמעט אף פעם אינו דרישת סף - לרוב הוא מופיע כ"יתרון" לצד הדרישות האמיתיות: JavaScript או TypeScript, Node.js והבנת ממשקים בכלל.

המסקנה המעשית: מי שמתחיל צריך להשקיע קודם ב-REST ובהבנת HTTP, ורק אז להוסיף את זה. אפשר לראות משרות רלוונטיות במשרות Node.js ובמשרות TypeScript, ואת המושג הכללי במה זה API.

שאלות נפוצות

GraphQL מחליף את REST?

לא. רוב הארגונים מריצים את שניהם - REST לשירותים פנימיים ולממשקים ציבוריים, ו-GraphQL לשכבה שמשרתת לקוחות עם צרכים משתנים. בלוח שלנו 26 משרות מזכירות REST API במפורש.

למה הוא מחזיר 200 גם כשיש שגיאה?

כי הבקשה עצמה הצליחה להגיע ולהתעבד; השגיאה מתוארת בתוך גוף התשובה, בשדה ייעודי. זה מבלבל מי שרגיל לקודי HTTP, ומחייב את הלקוח לבדוק את השדה הזה ולא רק את קוד הסטטוס.

הוא מהיר יותר מ-REST?

לא מעצם עצמו. הוא מקטין את כמות הנתונים שמועברת ואת מספר הקריאות מהלקוח, וזה מורגש ברשת איטית. מנגד, מימוש לא זהיר בצד השרת יכול להיות איטי משמעותית בגלל בעיית N+1.

צריך ללמוד אותו כדי להתקבל לעבודה?

ברוב המשרות בישראל לא. הוא מופיע כיתרון ולא כתנאי סף, ומי ששולט בממשקים בסגנון REST ובהבנת HTTP לומד אותו תוך שבועות. עדיף להשקיע קודם בבסיס.

איך מגנים על ממשק כזה מפני עומס?

בשלוש שכבות: מגבלת עומק קינון, ניקוד מורכבות לכל שאילתה עם תקרה, ורשימת שאילתות מאושרות מראש בממשקים פנימיים. בלי אלה, שאילתה מקוננת אחת יכולה להעמיס את השרת.

איך מתרגלים את זה בפרויקט אישי?

בונים סכימה קטנה מעל מקור נתונים אמיתי, מוסיפים שני טיפוסים מקושרים, ואז מודדים כמה שאילתות מסד נתונים יוצאות לכל בקשה. הרגע שבו רואים את בעיית N+1 בעיניים ומתקנים אותה שווה יותר מכל הסבר תיאורטי.

מה זה Federation?

גישה שמאפשרת לכמה שירותים לתרום חלקים לאותה סכימה אחת, כך שהלקוח רואה ממשק מאוחד. זה רלוונטי בארגונים עם ארכיטקטורה מבוזרת, ומוסיף שכבה נוספת של מורכבות תפעולית.