GraphQL: אלטרנטיבה ל-REST ב-HTTP

קיימים סטנדרטים אדריכליים רבים בקוד פתוח לבנייה והפצה של יישומים. REST (העברת מצב ייצוגי), SOAP (פרוטוקול גישה לאובייקט פשוט), RPC (קריאה פרוצדורלית מרוחקת) ו-API של GraphQL הם הפופולריים ביותר.

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

---

---

איפור של סרטון היום

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

מה זה GraphQL?

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

ה מפרט GraphQL מגדיר את שפת השאילתה וכיצד פועלים שרתי GraphQL. אתה יכול לבנות ולצרוך ממשקי API של GraphQL בשפות בצד השרת מ-Python ועד Javascript , וכל שפה התומכת ב-HTTP.

למה זה נקרא חשבון דרדסים

Meta בנתה את GraphQL בשנת 2012 כחלופה ל-REST לבנייה על HTTP. הם הוציאו את GraphQL כתקן קוד פתוח בשנת 2015. כיום, קרן GraphQL מפקחת על הפיתוח של מפרט GraphQL.

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

---

---

כמו כן, כל בקשות GraphQL מחזירות בסופו של דבר קוד סטטוס של 200 ללא קשר למצב הבקשה.

איך GraphQL עובד?

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

---

---

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

מדוע כדאי להשתמש ב-GraphQL?

REST הוא תקן קל לשימוש, ולרוב שפות התכנות יש כלים לבניית ממשקי API של RESTful במהירות. עם זאת, ישנן בעיות רבות בבנייה וצריכת ממשקי API של RESTful.

הנה כמה מהבעיות ב-REST שגורמות למפתחים להעדיף את GraphQL במקרים מסוימים.

שליפת נתונים לא יעילה

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

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

איך מוצאים את כתובת ה- ip של מדפסת

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

ממשקי API של GraphQL הם אינטראקטיביים; אתה יכול לציין את הנתונים שאתה צריך כדי לאחזר בתחביר קל וקריא.

{ 
    user(where: {age: {_eq: "89"}}) {  
        name 
        school(where: {alive: {_eq: true}}) { 
            bio 
            nationality 
        } 
    } 
} 

שאילתת GraphQL מעל שאילתות א מִשׁתַמֵשׁ סכימה עבור ערכים שבהם ה גיל השדה הוא 89. לשאילתה יש שאילתה מוטבעת עבור ערכים שבהם בחיים שדה מעריך נָכוֹן . הוא מחזיר את שדות השם, הביוגרפיה והלאום מהסכימה.

פיתוח מהיר

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

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

שפת ההגדרה של סכמת GraphQL

שפת GraphQL Schema Definition Language (SDL) מציינת את הסכימות עבור שירותי GraphQL.

קל לקרוא ולהבין את תחביר GraphQL SDL. תציין את המבנה של הסכימה שלך בקובץ עם ה .graphql אוֹ .graphqls סיומת.

type Human { 
    name: String! 
    age: Int! 
} 
  
input AddHuman { 
    name: String! 
    age: Int! 
} 
  
type Mutation { 
    CreateHuman(input: AddHuman!): Human! 
    DeleteHuman(id: Int!): String! 
    UpdateHuman(id: Int!): String! 
} 
  
type Query { 
    GetHuman(id: Int!): Human! 
    GetHumans: [Human!]! 
} 

קוד ה-GraphQL שלמעלה הוא הסכימה עבור GraphQL API המגדיר את מבנה ה-API עבור בקשות. הסכימה מגדירה את פונקציונליות ה-CRUD עבור ה-API.

בצד הלקוח, בהתבסס על מבנה הסכימה והנתונים או הפעולה של הלקוח, הלקוח יכול לבצע שאילתא (GET או DELETE ב-REST) ​​או א מוּטָצִיָה (PUT או POST).

הנה דוגמה לשאילתה של בן אנוש סכֵימָה.

query Human { 
    name 
    age 
} 

השאילתה למעלה תחזיר את הסכימה האנושית שֵׁם ו גיל נתוני שדה.

למוטציות GraphQL יש תחביר שונה למדי בניגוד לשאילתות. הנה דוגמה לפעולת מוטציה על בן אנוש סכֵימָה.

mutation { 
    CreateHuman(input:{ name:"man", age:1000000000000000,}) { 
        name 
        age 
    } 
} 

קוד המוטציה נכנס שֵׁם ו גיל שדות ללקוח ומחזירה את הנתונים מהשדות.

איך להכין מדבקות למברק

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

בניית API של GraphQL

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

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

GraphQL זוכה לאימוץ

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

אתה יכול לעיין בלקוחות GraphQL בקוד פתוח, בתיעוד GraphQL ובמפרט שלו כדי ללמוד עוד.