הארכיטקטורה הפופולרית של לקוח-שרת מחלקת את התקשורת לשני חלקים: אחד שנושא את כל המשימות הכבדות ומספק שירותים, הידוע כשרת, והשני שנהנה מהשירותים האלה, הידוע כלקוח.
בדרך כלל בתקשורת לקוח-שרת, הלקוח פשוט שולח בקשה שמבקשת משאבים או שירותים מהשרת, והשרת מגיב לבקשה זו.
לתקשורת לקוח-שרת, נדרש שלקוחות ושרתים יהיו בעלי ספריות המבינות את הפרוטוקול בו הם מתקשרים. פרוטוקול הוא שפה או קבוצה של כללים לתקשורת באינטרנט. הם מנועי תחבורה המקימים כמה כללים להעברת נתונים באינטרנט.
ההיבט השני ביותר חשוב בתקשורת הלקוח הוא פורמט ההודעה שעליו יכולים להסכים הלקוח והשרת. פורמט ההודעה מבוסס על כמה תבניות, ועל ידי אי-עקיבה אחרי תבניות אלה, לא הייתה מתרחשת תקשורת. פורמטי הודעות יכולים להיות דומים ל-XML, שמקיים תבנית, או קובץ JSON, שחייב לכלול זוגות ערך-מפתח מסוימים.
היבט חשוב נוסף בתקשורת מסוג זה להבין הוא שהיא מבוססת על מנגנון בקשה ותגובה, כלומר השרת מתקשר רק כשהלקוח מתחיל את התקשורת. עם REST ו-GraphQL, זה בעיקר חד-כיווני. זו בעיה בסיסית שייפתר על ידי טכנולוגיה כמו gRPC.
מדוע התפתח REST?
בשנות ה-90, פרוטוקול לקוח-שרת פופולרי בשם SOAP השתמש בפורמט הודעות XML עם תבנית קשה מקודדת. התבנית לפורמט הודעות היתה קשה מאוד. חוסר החופש הוא מה שגרם לנטישת SOAP ולהיווצרות REST.
REST נולד בגלל הפופולריות הגוברת של JavaScript, מה שהוביל לגידול בפופולריות של פורמט קבצי JSON. היה פשוט להבנה ונוח. פשוט היה לו זוגות מפתחות וערכים בפורמט הודעות שלו.
במילים פשוטות, Rest הוא מדריך להעברת הודעות JSON באינטרנט עם HTTP כפרוטוקול שלה (מנגנון ההפצה). עם Rest, אין צורך לדאוג ליצירת תבנית.
מה זה REST?
דיברנו על היווצרותו של REST. עכשיו בואו נצלול לתוך הטכנולוגיה המרכזית שלו. אז תן לי לספר לך שREST מיועד לעבור מצב ייצוגי. Rest הוא סגנון ארגון תוכנה מאורגן, API שמשתמשים בו הרבה בתעשייה.
סיבות לפופולריות ושימוש הנרחב בREST
- REST הוא פשוט ומאורגן עבור ארגוטקטורת התקשורת. בעת שימוש ב-R, לא יהיה צורך לדאוג לעיצוב הודעתך או הנתונים. אין צורך להתעסק עם פורמט הודעתך בכל פעם, מאחר שהוא מאורגן ומשמש בתעשייה.
- REST ניתן להתרחבות. אם השירות שלך גדל וזקוק לפונקציות נוספות, בקלות ניתן לשדרג את השרת שלך מבלי לדאוג לביצועים של REST של השרת, ואפשר ליצור פונקציות חדשות בבידוד מוחלט אלא אם הן משפיעות על הנתונים שלך.
- REST היא חסרת מצב. זה אומר שכל בקשה תהיה כוללת מידע שחייב להבין השרת. ארכיטקטורת השרת של השרת מאפשרת לו לזכור את מידע הבקשה זו, אך בארכיטקטורת REST, מצב המשתמש נשמר בצד הלקוח, מה שהופך את השרת ליעיל יותר ומעניק לו עבודה קלה יותר לתפקוד מדויק.
- לבסוף אך לא באופן פחות חשוב, Rest היא ארכיטקטורת ביצועים גבוהים ותומכת בטרנסה.
מתי להשתמש ב-REST
דמיינו שאתם בונים אתר למסעדה. יש לכם את כל התפריטים ברשת, ופריטי האוכל מחולקים לשלושה קטגוריות:
- מבשלים
- תערובת ראשית
- משקאות
עכשיו, נניח שאתם רוצים לראות את כל המשקאות ברשת. בארכיטקטורת Rest, אפשר לחלק בקלות ובאופן עקבי את כל המשאבים שלכם על שיאי API. כמובן, אפשר להשתמש באימות מרובה עליהם כדי להבטיח את בטיחותם.
במקרה כזה, אנו שולחים בקשת GET לשרת לכיוון שבו אפשר לקבל את מידע משאב המשקאות.
באופן דומה, אפשר לבצע את כל CRUD (יצירה, קריאה, עדכון, מחיקה) ב-API של Rest, מה שהופך אותו למתאים לפרויקטים גדולים שאינם דורשים העברת מידע סופרית ואינם חייבים להיות בזמן אמת.
Rest עובד הכי טוב עבור פרויקטים שבהם העברת מידע יעילה היא גורם חשוב. טרנסה היא תכונה נוספת של REST שמועילה ליישומים סטנדרטיים כמו יישומי הזמנת אוכל, יישומי הזמנת מלונות, אתרי בלוג, אתרי פורום וכד'.
מגבלות ובעיות עם REST
REST זה מדהים, אבל יש לו גם כמה חסרונות חשובים במקרים מסוימים. בואו נדבר עליהם.
- הצורך בתקשורת דו-כיוונית.
מה אם השרת צריך לשלוח נתונים ללקוח? השרת רוצה להתחיל את התקשורת. במבנה של REST, זה לא אפשרי. כמובן, אפשר להשתמש בטריקים, אבל הם לא פרקטיים. - דמיינו שאתם בונים אתר שמציג תוצאות ספורט בזמן אמת. איך תתארגנו את השרת לשלוח בקשה ללקוח לעדכן את נתוני הסקור? אפשר לגרום ללקוחות לשלוח בקשות כל 10 שניות, אבל זה בכלל לא פרקטיקה טובה. זה יעמיד לחץ על השרת, מה שעשוי לגרום לבעיות במהירות.
- מבנה REST הוא טהור בקשה ותגובה ולא תומך בזרימת נתונים (עיבוד אירועים רציף).
- המאפיין של REST להיות ללא מצב יכול להיחשב גם ברכה וגם קללה מכיוון שאי אפשר לקבוע את מצב הנתונים במבנה REST.
למה gRPC התחיל להתקיים?
כדי להתמודד עם הבעיה הראשונה של REST, שהיא הצורך בתקשורת דו-כיוונית, הומצא WebSocket, שמאפשר לשרת להתחיל את התקשורת, אך הבעיה עם זה היא שאין לו פורמט. הוא פשוט שולח בתים ואין שום מגבלות.
ה-Websockets לא עצמם הבעיות, אבל הבעיה האמיתית היא שכל סוג תקשורת דורש פרוטוקול, וכל פרוטוקול דורש ספריית לקוח שיכולה לתקשר באמצעות הפרוטוקול הזה.
אם אתה יוצר יישום Python העובד על ארכיטקטורת Rest, תצטרך לקולטן HTTP שיכול לתקשר עם השרת. במקרים רבים, ספריות הלקוח מיוצרות על ידי צד שלישי, בעיקר מפתח עצמאי. שימוש בספריות צד שלישי יכול לחשוף את האבטחה שלך, וכל היישום שלך יהיה תלוי בצד שלישי עבור תקשורת.
במקרה של יישום אינטרנט, הדפדפן משמש כמו ספריית הלקוח, אך עבור פרויקטים לא אינטרנט, תצטרך ספריית לקוח צד שלישי. אם אתה חושב ליצור אחת משלך, אז זכור שזה לא כל כך קל, ותעמוד בפני הטלת משמעת על תחזוקת יישום נוסף.
אז, כדי לטפל בכמה בעיות עם Rest וכדי לטפל בבעיות עם ספריות הלקוח, גוגל המציאה את gRPC ב-2015.
עבור gRPC, ספריית לקוח אחת מתחזקת על ידי גוגל עבור כמעט כל השפות הפופולריות. היא משתמשת ב-HTTP 2 תחת השטח וב-protocol buffer (protobuf) כפורמט הודעות.
אין צורך לדאוג לגבי ספריית לקוח כלשהי, שכן גוגל מתחזקת אותה עבורך ועבור כמעט כל שפת התכנות. ספריית לקוח אחת ומרכזית היא אחת העוצמות העיקריות של gRPC.
תועלת נוספת של gRPC היא פורמט הודעות שהיא משתמשת בו. מסרים מקודדים בפרוטוקול בול הם נטולי שפה, כך שאפשר ליצור לקוחות ב-Python ושרתים ב-Go ועדיין לתקשר מבלי לעשות בעיה.
gRPC הוא למעשה ספריית לקוח אחת ופרוטוקול אחד שניתן להשתמש בו בכל מכשיר.
מהו gRPC?
gRPC משתמש ב-protobuf לתקשורת. הוא ממיר קבצי proto לפורמט בינארי ושולח אותם לשרת, ובצד השרת, הם ממירים חזרה לפורמט המקורי. ככה זה עובד עם protobuf.
ל-gRPC יש צורות תקשורת שונות. אפשר לחשוב עליהן כעל תכונות של gRPC.
תכונות של gRPC
- בקשה יחידה:זוהי סוג פשוט של תקשורת בקשה-תגובה שבה הלקוח שולח בקשת proto ולאחר קבלתה, השרת ממתין זמן מה לבצע תהליך כלשהו ואז מחזיר תשובה מסוימת.
- זרימת שרת:בעת ביצוע בקשה יחידה, מגיעה תגובה של זרם של נתונים מהשרת. לדוגמה, כשלוחץ על סרטון, הרבה נתונים קשורים לסרטון זורמים מצד השרת.
- זרימת לקוח:זהו ההפך לזרימת השרת. כאן הלקוח שולח הרבה נתונים בבת אחת לשרת. לדוגמה, זה קורה כשאתה משתף קובץ גדול באינטרנט או מעלה תמונה או סרטון לאינטרנט. הלקוח שולח באופן קבוע נתונים לצד השרת.
- זרימה דו-כוונית:בסוג זה של תקשורת, הלקוח והשרת שולחים מספר הודעות. צ'אטינג הוא דוגמה מצוינת לכך.
אלו שלושה תכונות פופולריות של gRPC המאפשרות לו להיות כל כך חזק.
מתי להשתמש ב-gRPC
בנוגע לתכונות של gRPC, ראינו כמה מקרים לשימוש ב-gRPC. בואו נדמיין שאתה רוצה ליצור אפליקציית צ'אט. אתה לא תשתמש ב-API הרגיל כיוון שהוא לא יאפשר זרימה מהירה של תקשורת דו-כיוונית. לשם כך, נשתמש בזרם gRPC, שיספק כמה יתרונות נוספים מעבר למהירות.
ראשית, התנהגותו הנייטרלית לשפת התכנות לא משנה באיזו שפת תכנות כתב השרת או הלקוחות האחרים. תקשורת עדיין יכולה להתבצע כל עוד פורמט ההודעה נקבל.
לכן, עם תכונה זו, גרסת האנדרואיד של אפליקציית הצ'אט יכולה לתקשר עם גרסת iOS ולהפך.
בעיות עם gRPC
יש בעיות עם הכול, כולל gRPC.
- תמיכה מוגבלת בדפדפנים: gRPC משתמש ב-HTTP 2, כך שקשה לקרוא לשירות gRPC ישירות מהדפדפן, מה שלפעמים דורש הקמת פרוקסי.
- צורה לא קריאה: כפי שכולנו יודעים, gRPC משתמש בפורמט בינארי שאינו קריא על ידי בני אדם. זו חסרון במקרים מסוימים.
- חוסר בגרות: gRPC פותח בשנת 2015, כך שהוא עדיין קצת לא בשל בהשוואה ל-REST, וצריך להתמודד עם מספר באגים ובעיות.
- בעיות למידה: REST ו-GraphQL משתמשים ב-JSON, שקל ללמוד. רוב האנשים ינסו לדבק בהם מאחר ו-protobuf הוא עדיין נושא חדש ומורכב, כך שיהיה קשה למצוא מומחים ל-gRPC.
REST מול gRPC:
כעת נדון בהבדלים הטכניים בין REST ל-gRPC.
פורמט הודעה:
הפורמט המשמש ב-REST הוא בעיקר JSON (לפעמים פורמט XML), שהוא צורה קריאה יותר וקלה יותר לעיבוד. אין צורך לדאוג לגבי השֶׂכֶת ב-Rest. לעומת זאת, gRPC משתמש בבלוק פרוטוקול להמיר נתונים. הצורה המועתקת היא קלה יותר ומהירה יותר לנסיעה. הוא בפורמט בינארי, כך שהוא ממיר וממיר נתונים להעברתם.
HTTP 1.1 מול HTTP 2:
ממשק ה-API של Rest בדרך כלל משתמש ב-HTTP 1.1 כפרוטוקול שלו, ואילו gRPC משתמש ב-HTTP 2 כפרוטוקול מתחת למכסה. ממשק ה-API של Rest יכול עדיין להשתמש ב-HTTP 2 אך עדיין מוגבל בגלל מנגנון הבקשה-תגובה. gRPC משתמש ב-HTTP 2 ומנצל את התמיכה ב-HTTP 2 גם בתגובת לקוח וגם בתקשורת דו כיוונית. זהו עוד אחד ההיבטים שהופך את gRPC למעטה יותר מ-REST. הוא יכול לנהל בקשות חד כיווניות כמו HTTP 1.1 ובקשות דו כיווניות בו זמנית כמו HTTP 2.
מועט זמן המתנה:
המועט זמן המתנה והמהירות הגבוהה של gRPC בתקשורת הופכות אותו לשימושי לחיבור למערכות המורכבות מארכיטקטורת מיקרוסרביסים קלים, מה שמשפר את יעילות שיתוף המסרים. ברוב המקרים של הרשת, זמן המתנה של REST הוא 25 מילי-שניות, ואילו זמן המתנה של gRPC הוא הרבה פחות משל REST.
גבול עיליות:
ל-Rest יש גבול עיליות מקסימלי של 45MB כששולחים הודעות יוצאות, ואילו ל-gRPC אין גבול, כך שההודעה היוצאת שלך יכולה להיות כה כבדה כפי שתרצה.
אבטחה:
במובן של אבטחה, Rest יאט מכיוון שהוא משתמש ב-HTTP 1.1 ובפורמט JSON, שהוא קל לפענח ולגשת אליו. לעומת זאת, gRPC משתמש ב-HTTP 2, שהוא הרבה יותר בטוח, ומשתמש ב-protobuf, שהוא בפורמט בינארי וקשה לפענח.
מהירות:
שוב, gRPC זוכה, מאחר שהוא מציע מהירות גבוהה פי 10 מאשר Rest, וזה מאחר שהוא משתמש ב-HTTP 2 כפרוטוקול וב-protobuf כפורמט הודעות.
פונקציית יצירת קוד
Rest אינה מספקת תכונות יצירת קוד מובנות מפני עצמם, כלומר המפתח זקוק ליישומים שלישיים לייצר קוד API, ובעוד שgRPC מספק תכונות יצירת קוד מובנות מפני עצמם בזכות מהדר protobuf שלו, שהוא תואם שפות תכנות רבות. זהו יתרון נוסף, במיוחד עבור ארכיטקטורות של מיקרוסרביסים.
שער Memphis REST
כדי לאפשר יצירת הודעות דרך קריאות HTTP למגוון שימושים וקלות השימוש, Memphis הוסיף שער HTTP לקבל בקשות מבוססות REST (=הודעות) ולייצר אותן הודעות לתחנה הנדרשת.
שימושים נפוצים שמשתלטים משער REST הם:
- ייצור אירועים ישירות מהקדמי
- חיבור Debezium באמצעות שרת HTTP
- קיצורי דרך ArgoCD
- אינטגרציה PostHog
- קבלת נתונים מ-Fivetran/Rivery/כל פלטפורמת ETL באמצעות קריאות HTTP
שער Memphis REST + תבנית JSON יכולה להוות שילוב חזק להגדלת איכות הנתונים ולהבטחת תקשורת בריאה בין אפליקציות או שירותים.
Memphis יתמוך בקרוב גם ב-gRPC.
מסקנה
בסופו של דבר, אני רוצה לומר ש-REST היא עדיין הארכיטקטורה הנפוצה והפופולרית ביותר, וזה בלתי אפשרי לנטוש אותה. ל-REST יש הרבה חסרונות, כמו חוסר זרימת נתונים, העדר תקשורת דו-כיוונית, מהירות איטית וכו', אך היא הכי טובה ליישומים סטנדרטיים שאנו רואים בחיי היום-יום.
מצד שני, gRPC, שהוא צעיר וקשה ללמוד, מספק דברים רבים כמו זרימת נתונים גבוהה גם בצד הלקוח וגם בצד השרת, זרימת נתונים דו-כיוונית טובה, היא מהירה ודחוסה, ומשתמשת ב-HTTP 2. עקב ביצועים מהירים, gRPC היא הכי מתאימה ליישומים עם עבודה גבוהה כמו זרם וידאו, זרם שירים, משחקים מקוונים, שיתוף קבצים ויישומי צ'אט.