WEBA
מונחים·פיתוח ווב

GraphQL: מה זה?

חלופה ל-REST שבה הלקוח מבקש בדיוק את השדות שהוא צריך, בבקשה אחת.

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

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

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

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

כלים שהמונח חי בהם