מה זה GraphQL?
GraphQL הוא שפת שאילתות קוד פתוח עבור APIs, שהופקה לראשונה על ידי פייסבוק בשנת 2012 ושוחררה לציבור בשנת 2015. היא מציעה חלופה גמישה ויעילה ל-REST APIs המסורתיים על ידי כך שהיא מאפשרת ללקוחות לבקש רק את הנתונים הספציפיים שהם צריכים, פותרת בעיות של שליפת יתר ושליפת חסר שמתרחשות לעיתים קרובות עם REST APIs.
אחת הסיבות לפופולריות הגוברת של GraphQL היא האופי המונחה לקוח שלה. זה הופך אותה למתאימה במיוחד ליישומים מודרניים שבהם הביצועים, ההתרחבות וחוויות המשתמש החלקות הם קריטיים. GraphQL מאפשרת ללקוחות לשלב מספר משאבים לבקשה אחת, מפחיתה את תעבורת הרשת ועושה אותה פתרון מצוין עבור אפליקציות ניידות עם רוחב פס מוגבל או צרכים מורכבים בחזית.
חברות גדולות כמו GitHub, Twitter, Indeed ו-Shopify אימצו את GraphQL, ומדגישות את הפוטנציאל שלה לייעל את פיתוח ה-API ולשפר את האינטראקציות בין הלקוח לשרת.
ממשק GraphQL
ב-GraphQL, ממשק פועל בצורה דומה לממשקים בתכנות מונחה עצמים. זהו סוג אבסטרקטי המגדיר סט של שדות משותפים שיכולים להתממש על ידי מספר סוגי אובייקטים. זה מבטיח שהלקוח יכול לשאול בביטחון את השדות המשותפים הללו בין סוגים שונים.
type Query {
findVehicles(): [Vehicle!]!
}
interface Vehicle {
id: ID!
name: String!
model: String
}
type Car implements Vehicle {
id: ID!
name: String!
model: String
# Specific to Car
fuelType: String!
}
type Bicycle implements Vehicle {
id: ID!
name: String!
model: String
# Specific to Bicycle
gearCount: Int!
isElectric: Boolean!
}
שאילתת לקוח GraphQL:
query findVehicles() {
findVehicles() {
vehicle {
id,
name,
model,
... on Car {
fuelType
}
... on Bicycle {
gearCount,
isElectric
}
}
}
}
בדוגמה זו, השדות הנפוצים כמו id, name, וmodel זמינים בכל סוגי האובייקטים המיישמים את ממשק Vehicle. עם זאת, השדות הספציפיים לסוג כמו fuelType עבור Car וgearCount וisElectric עבור Bicycle יכולים להיות משולבים באמצעות פגמים.
אם הלקוח זקוק רק לשדות נפוצים, הוא יכול להשאיר את הפגמים:
query findCars() {
findCars() {
car {
id,
name,
model
}
}
}
יתרונות השימוש בממשקים
- שימוש חוזר בקוד: שדות נפוצים יכולים להיות מוגדרים בממשק ולשתף בין מספר סוגים, מה שמפחית חזרות.
- לוגיקה פשוטה בצד הלקוח: לקוחות לא צריכים בדיקות תנאיות עבור סוגי אובייקטים. הם יכולים לבקש סוגים מדויקים ולטפל בתגובות בביטחון.
- הרחבת סכימה: הוספת שדה נפוץ חדש הופכת לקלה יותר מכיוון שהיא צריכה להיות מוגדרת רק בממשק.
- מבנה מחייב: ממשקים מחייבים מבנה משותף בין כל הסוגים המיישמים, מה שמבטיח עקביות (למשל, כל הרכבים חייבים להיות בעלי
id,name, וmodel). - שאילתות מאוחדות: במקום לשאול סוגים שונים בנפרד, לקוחות יכולים לשאול ממשק אחד כדי להשיג נתונים מכל הסוגים המיישמים.
- תיעוד משופר: על ידי הגדרת התנהגות נפוצה באמצעות ממשקים, קל יותר לצרכני API להבין ולעבוד עם סוגים קשורים.
איחוד GraphQL
איחוד בִּ GraphQL הוא סוג מופרש שמאפשר ללקוחות לשאול סוגי אובייקט שונים שקשורים באופן מסוים דרך שדה אחד. לעומת פניות, איחודים אינם דורשים מסוגי החברים לשתף שדות משותפים. זה גורם לאיחודים להיות אידיאליים לטיפול במקרים שבהם סוגים קשורים יש להם מבנה שונה אך עדיין נדרשת שאילתה משותפת.
type Query {
getPurchaseItems(): [PurchaseItem!]!
}
union PurchaseItem = Product | Service | Subscription
type Product {
id: ID!
productName: String!
price: Float!
}
type Service {
id: ID!
serviceName: String
duration: Float
}
type Subscription {
id: ID!
planName: String
billingCycle: String
}
שאילתת לקוח GraphQL:
query getPurchaseItems() {
getPurchaseItems() {
purchaseItems {
... on Product {
id
productName
price
}
... on Service {
id
serviceName
duration
}
... on Subscription {
id
planName
billingCycle
}
}
}
}
בדוגמה זו, מוצר, שירות ומינוי הם כל הם סוגים נפרדים השייכים לאיחוד PurchaseItem. הלקוח יכול לשאול את שלושת הסוגים באמצעות רסימות בשאילתה יחידה, גם אם אין להם שדות משותפים.
הערה חשובה על איחודים, סוגי החבר של סוג איחוד חייבים להיות כלם סוגי אובייקט בסיסיים; סוגים סקאלריים, פניות ואיחודים לא יכולים להיות סוגי חבר של איחוד. באופן דומה, סוגים מעטופים לא יכולים להיות סוגי חבר של איחוד.
יתרונות של שימוש באיחודים
- קיבוץ גמיש: איחודים מאפשרים לשאול סוגים קשורים שאין להם שדות משותפים, מה שייתכן שיהיה מסובך לטפל בזה אחרת.
- טיפול פשוט בשגיאות: ללקוחות ניתן להשתמש ברסימות כדי לשאול סוגים ספציפיים, מה שמפחית את הצורך בלוגיקה תנאית מורכבת בצד הלקוח.
- טיפול בנתונים הטרוגניים: שאילתה יחידה יכולה לשלוף נתונים ממספר סוגים, וכך פשוטים את הטיפול במבני נתונים מגוונים.
- שימושי תגובת שגיאה: האיחודים שימושיים במיוחד כאשר ברצונך לשלב תגובות להצלחה ופרטי שגיאה לתוך סוג תגובה אחת, מאפשרים ללקוחות לטפל בהם ביעילות.
בסיכום
ממשפט כללי ומובנה, ממשפטי הממשק והאיחודים ב-GraphQL מציעים דרכים עוצמתיות למבנה הסכמת ה-GraphQL שלך, מאפשרות גמישות ומפשטות את האינטראקציות בין הלקוח והשרת. ממשפטי הממשק מאפשרים שדות משותפים בין סוגים, תומכים בשימוש חוזר בקוד ובהרחבות סכמה קלות יותר. האיחודים, מצד שני, מציעים דרך לשאילת סוגים שונים יחד בלי לדרוש שדות משותפים.
Source:
https://dzone.com/articles/a-beginners-guide-to-graphql-interfaces-and-unions