מה זה gRPC ולמה שירותים פנימיים משתמשים בו

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

מאיפה זה בא בכלל

gRPC היא מסגרת עבודה (framework) שפיתחה גוגל לתקשורת בין שירותים, מבוססת על עיקרון ישן יחסית - קריאה לפרוצדורה מרוחקת, או RPC (Remote Procedure Call). הרעיון של RPC הוא שאתם קוראים לפונקציה בשירות אחר בדיוק כמו שהייתם קוראים לפונקציה רגילה בקוד שלכם, והתשתית מסתירה מכם את כל הפרטים של איך הבקשה עוברת ברשת.

מה שהופך את gRPC למהיר

יש שני מרכיבים טכניים שנותנים ל-gRPC את היתרון שלו על פני REST רגיל.

הראשון הוא Protocol Buffers, או פרוטובאף בקיצור - פורמט בינארי לסידור נתונים (serialization) במקום JSON טקסטואלי. הודעת פרוטובאף קטנה משמעותית מאותו מידע ב-JSON, ומהירה יותר לקרוא ולכתוב, כי המחשב לא צריך לפרש טקסט - הוא קורא בייטים בפורמט קבוע מראש.

השני הוא HTTP2 כפרוטוקול תחתון, במקום HTTP1.1 שרוב ה-API הרגילים עדיין משתמשים בו. HTTP2 תומך בריבוב (multiplexing) - כמה בקשות יכולות לזרום על אותו חיבור רשת בו זמנית, בלי לחכות אחת לשנייה, ותומך גם בהזרמת נתונים דו-כיוונית.

איך זה נראה בפועל

במקום לכתוב תיעוד REST עם endpoints ופורמטים, מגדירים בפרוטובאף "חוזה" (schema) שמתאר בדיוק אילו פונקציות קיימות ואילו נתונים כל אחת מקבלת ומחזירה. מהחוזה הזה, הכלים של gRPC מייצרים אוטומטית קוד לקוח ושרת בשפות תכנות שונות - כך ששירות שכתוב בפייתון יכול לקרוא בקלות לשירות שכתוב ב-Go, וכל אחד מקבל קוד מתאים לשפה שלו.

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

אז למה לא כולם משתמשים בזה

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

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

מתי כדאי לשקול gRPC

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

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

איפה לומדים את זה מעשית

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

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

הצטרפו לקהילה בדיסקורד

לסיכום

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