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

עקרון הגבול (The Boundary Principle)

ארכיטקטורה עוסקת בפשרות (trade-offs), לא ב"אלופים". השאלה הנכונה היא אף פעם לא "מה הכי מהיר?" או "מה הכי חדש?". היא "מי יושב בצד השני של הכבל, ומה השליטה שלו?". פרוטוקולים הם אובייקטים של גבולות (boundary objects). בחירה בטעות לא רק תאט אתכם; היא תטמיע טעויות במערכת שלכם למשך שנים.

APIs ציבוריים: REST אינו משעמם, הוא אחראי

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

REST שורד כאן כי הוא האינטרנט עצמו. שיטות HTTP, קודי סטטוס ו-JSON הם השפה המשותפת. מטמון (Caching) אינו מחשבה מאוחרת; זוהי תשתית שכבר קיימת. דפדפנים, CDNs ו-edge caches מבינים כותרות Cache-Control ואימות ETag באופן טבעי. אתם יכולים להציב REST API מאחורי CDN סטנדרטי ולקבל חיסכון מיידי ברוחב פס מבלי לכתוב שורה אחת של לוגיקת caching. זה משנה כאשר התעבורה הציבורית אינה צפויה ואתם משלמים על כל גיגה-בייט שיוצא מהענן שלכם.

GraphQL, לעומת זאת, מביא איתו "מס" כבד לגבול ציבורי. נקודות קצה (endpoints) ציבוריות של GraphQL זקוקות לניתוח עלות שאילתות, הגבלת עומק ודירוג מורכבות כדי למנוע משאילתה אחת רשלנית או זדונית לרסק את מסד הנתונים שלכם. אתם לא רק מספקים API; אתם בונים מנוע ביצוע שאילתות, אסטרטגיית הגבלת קצב (rate-limiting) ומודל חיוב למשאבי מחשוב. אלא אם כן יש לכם את הכוח התפעולי של הפלטפורמות הגדולות ביותר, העומס הזה הוא פזיז מדי עבור שטח פנים ציבורי. REST קובע מגבלות (guardrails) כברירת מחדל. כל endpoint עושה דבר אחד. הצרכנים מושכים בדיוק את מה שאתם מציעים, ולא כל מה שהם יכולים לדמיין.

שירותים פנימיים: שליטה על כל הצינור

בתוך הארגון שלכם, השיח משתנה. אתם שולטים גם בלקוח וגם בשרת. אתם יכולים להכתיב את ערימת הטכנולוגיות (technology stack) עבור כל שירות בשרשרת הקריאות. כאן gRPC מצדיקה את עצמה.

ראשית, הפסיקו להתייחס ל-JSON כאל דבר קדוש. Protocol Buffers מבצעים סריאליזציה בערך פי שלושה מהר יותר מ-JSON. המטען (payloads) קטן יותר מכיוון שהפורמט הוא בינארי. ברשת פנימית עמוסה, המילישניות והמגה-בייטים הללו מצטברים לכסף אמיתי ולהפחתת tail latency. חשוב מכך, Protobuf מעניק לכם חוזה (contract) מחמיר. כשאתם משנים סוג שדה או משנים שם של הודעה, השבירה מתרחשת בזמן הקומפילציה, ולא בשלוש לפנות בוקר בייצור (production) כאשר שירות downstream מתחיל לזרוק חריגות parse.

gRPC רץ על גבי HTTP/2, כך שאתם מקבלים דחיסת כותרות, זרמים מרובים (multiplexed streams) וסמנטיקה של סטרימינג אמיתי. אם אתם מעבירים אירועים בעלי תפוקה גבוהה בין שירותים או דוחפים עדכונים בזמן אמת, סטרימינג בצד השרת ודו-כיווני הם תכונות טבעיות, ולא פתרונות מעקף של long-polling שנדבקו ב"סלוטייפ" למסגרת של בקשה-תגובה.

יש כאן מלכודת קשה: אל תפנו את gRPC ישירות לדפדפן. מודלים של רשת בדפדפן אינם מדברים HTTP/2 כפי ש-gRPC מצפה. אתם תמצאו את עצמכם מחברים grpc-web ופרוקסי כמו Envoy לערימה שלכם רק כדי לגרום לדפדפן לדבר עם ה-backend. זה לא באג; זה סימן לגבול. שמרו את gRPC מאחורי חומת האש שלכם, בין שירותים שסומכים זה על זה, והתייחסו למורכבות ה-debugging שלו כמחיר המהירות. מטען בינארי לא נראה טוב בעין בקובץ לוג כפי ש-JSON נראה.

ממשקי משתמש מורכבים ומובייל: הנישה של GraphQL

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