كل مايكروسيرفيس لازم يحكي مع خدمات تانية، والسؤال يلي بيواجه أي فريق وهو يصمم هالتواصل: REST المعتاد، ولا gRPC؟ هاد شرح عملي للفرق الحقيقي بينهم، ومتى كل واحد أنسب.
REST — بروتوكول العالم كله
REST بيستخدم HTTP العادي (غالبًا HTTP/1.1) وبيبعت البيانات كنص JSON قابل للقراءة المباشرة:
GET /orders/42 HTTP/1.1
Host: order-service
HTTP/1.1 200 OK
Content-Type: application/json
{ "orderId": "42", "status": "shipped", "total": 89.5 }
- ✅ سهل التجربة — أي متصفح أو أداة زي curl أو Postman بتناديه مباشرة وبتقرا الرد بعينك
- ✅ معيار عالمي — كل لغة ومكتبة بتدعمه بلا أي إعداد إضافي
- ✅ مناسب جدًا لـ API عام يتعامل معه مطورين خارجيين أو تطبيقات ويب بالمتصفح
- ❌ نص JSON أثقل من ترميز ثنائي، وكل طلب غالبًا بيفتح اتصال جديد بـ HTTP/1.1
gRPC — سرعة وكفاءة للتواصل الداخلي
gRPC إطار عمل من Google، بيستخدم Protocol Buffers (ترميز ثنائي مضغوط) بدل JSON، وبيشتغل فوق HTTP/2 (اتصال واحد مُعاد استخدامه لعدة طلبات):
// order.proto — العقد بين الخدمتين
service OrderService {
rpc GetOrder (GetOrderRequest) returns (Order);
}
message GetOrderRequest { string order_id = 1; }
message Order {
string order_id = 1;
string status = 2;
double total = 3;
}
- ✅ رسائل أصغر وأسرع — protobuf ثنائي ومضغوط، أخف بكتير من نص JSON المكافئ
- ✅ HTTP/2 بيدعم طلبات متزامنة كتير على نفس الاتصال، وStreaming بالاتجاهين
- ✅ عقد صارم (
.protofile) بيولّد كود Client وServer تلقائيًا بأي لغة - ❌ ما بينقرا مباشرة — لازم أدوات خاصة (زي grpcurl) للتصحيح
- ❌ المتصفح ما بيقدر يناديه مباشرة، لازم طبقة gRPC-Web وسيطة
جدول المقارنة
| المعيار | REST | gRPC |
|---|---|---|
| صيغة البيانات | JSON نصي | Protocol Buffers (ثنائي) |
| البروتوكول | HTTP/1.1 غالبًا | HTTP/2 |
| قابلية القراءة | مباشرة، بأي أداة | تحتاج أدوات خاصة |
| الأداء تحت حمل عالٍ | جيد | أفضل — رسائل أصغر واتصال مُعاد استخدامه |
| استدعاء من المتصفح | مباشر (fetch) | يحتاج طبقة gRPC-Web وسيطة |
| Streaming ثنائي الاتجاه | يحتاج WebSocket منفصل | مدعوم أصلًا بالبروتوكول |
| الأنسب لـ | API عام، عملاء خارجيين، متصفحات | تواصل داخلي كثيف بين خدماتك |
متى تختار كل وحدة؟
- API عام بيتعامل معه مطورين خارجيين أو تطبيق ويب بالمتصفح؟ → REST أسهل وأوسع دعمًا
- تواصل داخلي بين عشرات الخدمات بحمل عالٍ، وإنت متحكم باللغة والطرفين؟ → gRPC أسرع وأخف
- محتاج Streaming حقيقي بالاتجاهين (زي تتبع حالة لحظي)؟ → gRPC مدعوم أصلًا بلا حلول جانبية
الخلاصة
مافي "أفضل" مطلق هون — كتير أنظمة إنتاجية حقيقية بتستخدم الاثنين مع بعض: gRPC للتواصل الداخلي الكثيف بين الخدمات، وREST (عبر API Gateway) للواجهة يلي بتوصل للعالم الخارجي والمتصفح.
ابدأ مسار المايكروسيرفيس الكامل بالعربي — أو شوف درس gRPC بالتفصيل.