تت adopt الفرق عادة gRPC لأحد سببين.
السبب الجيد هو أنهم يمتلكون مجموعة متزايدة من الخدمات الداخلية ويريدون عقدًا أكثر صرامةً وأفضل تجهيزًا من JSON غير النظامي عبر HTTP. السبب السيئ هو أنهم سمعوا أن REST هو "تراثي" ويرغبون في استبدال كل API دون وضوح حول المشكلة التي يحلونها.
gRPC ممتاز في الحالة الأولى. وغالبًا ما يكون غير ضروري في الثانية.
## ما الذي يحسّن gRPC فعلاً
لإجراء المكالمات من خدمة إلى أخرى، يوفر لك gRPC عددًا من المزايا المعنوية في نفس الوقت:
- عقد من نوع schema-first في ملفات `.proto`
- عملاء وخوادم مولدة
- تسلسل ثنائي مضغوط
- أنماط تدفق مدمجة
تقلل تلك المجموعة من الانجراف في الواجهات بين الخدمات.
إليك نوع العقد الذي يتحسن مع مرور الوقت أكثر من شكل JSON موثق بشكل فضفاض:
```proto
syntax = "proto3";
service UserService {
rpc GetUser (GetUserRequest) returns (GetUserResponse);
}
message GetUserRequest {
string id = 1;
}
message GetUserResponse {
string id = 1;
string email = 2;
bool active = 3;
}
بمجرد وجود هذا المخطط، يتوقف العقد عن العيش في رسائل Slack وصفحات الويكي نصف المحدثة.
أين يساعد في الممارسة العملية
الفائدة الأكبر غالبًا ليست في سرعة التسلسل الخام. إنها انضباط الواجهة.
إذا كانت خمس خدمات جميعها تحتاج إلى التحدث إلى نفس خدمة الفوترة أو الهوية، فإن العملاء المولدين والمخطط الثابت يقللان من الكثير من الكسر العرضي. تتوقف عن كتابة أنواع الحمولة يدويًا في كل مستهلك وتبدأ في معاملة حدود الخدمة كواجهة منتج حقيقية.
هذا الأمر يكون أكثر أهمية مع مرور الوقت من تقليل بضع بايتات عن البيانات المرسلة.
أين لا يزال REST يحقق انتصارات
لا يزال لدى REST مزايا قوية:
- من السهل تصحيح الأخطاء باستخدام أدوات شائعة
- يعمل بشكل طبيعي مع المتصفحات
- يتوافق بشكل نظيف مع واجهات برمجة التطبيقات العامة
- يناسب التخزين المؤقت وسمات HTTP بشكل جيد
لهذا السبب ينتهي الأمر بالعديد من الأنظمة بنموذج مقسوم:
- REST أو HTTP JSON على الحافة
- gRPC داخل الشبكة
غالبًا ما تكون هذه هي الهندسة المعمارية الأكثر براغماتية.
التنازلات
gRPC ليس مجانيًا.
تتحمل ما يلي:
- إدارة مخطط protobuf
- كود مولد في سلسلة الأدوات
- فحص أقل راحة من JSON العادي
- مزيد من الاحتكاك للعملاء الأصليين في المتصفح ما لم تضف gRPC-Web أو جسر آخر
هذا مقبول عندما تكون البيئة تحت السيطرة. لكنه أقل قبولًا عندما يجب أن يكون API قابلاً للاستخدام على نطاق واسع.
قاعدة قرار جيدة
استخدم gRPC عندما:
- تكون المتصلات في الغالب خدمات داخلية
- تكون العقود القوية مهمة
- تريد عملاء مولدين عبر الفرق أو اللغات
استمر في استخدام REST عندما:
- يكون API عامًا
- تكون المتصفحات مستهلكين من الدرجة الأولى
- تكون سمات HTTP والتخزين المؤقت أكثر أهمية من سهولة استخدام RPC
المسألة ليست اختيار فائز لكل نظام. بل النقطة هي التوقف عن استخدام بروتوكول واحد بدافع العادة.
قراءة إضافية