تخطَّ إلى المحتوى

٢١ يوليو ٢٠٢٦

الفرق بين gRPC و REST بالعربي: أيهم تستخدم بين خدماتك؟

شارك المقال:

كل مايكروسيرفيس لازم يحكي مع خدمات تانية، والسؤال يلي بيواجه أي فريق وهو يصمم هالتواصل: 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 بالاتجاهين
  • ✅ عقد صارم (.proto file) بيولّد كود Client وServer تلقائيًا بأي لغة
  • ❌ ما بينقرا مباشرة — لازم أدوات خاصة (زي grpcurl) للتصحيح
  • ❌ المتصفح ما بيقدر يناديه مباشرة، لازم طبقة gRPC-Web وسيطة

جدول المقارنة

المعيارRESTgRPC
صيغة البياناتJSON نصيProtocol Buffers (ثنائي)
البروتوكولHTTP/1.1 غالبًاHTTP/2
قابلية القراءةمباشرة، بأي أداةتحتاج أدوات خاصة
الأداء تحت حمل عالٍجيدأفضل — رسائل أصغر واتصال مُعاد استخدامه
استدعاء من المتصفحمباشر (fetch)يحتاج طبقة gRPC-Web وسيطة
Streaming ثنائي الاتجاهيحتاج WebSocket منفصلمدعوم أصلًا بالبروتوكول
الأنسب لـAPI عام، عملاء خارجيين، متصفحاتتواصل داخلي كثيف بين خدماتك

متى تختار كل وحدة؟

  • API عام بيتعامل معه مطورين خارجيين أو تطبيق ويب بالمتصفح؟REST أسهل وأوسع دعمًا
  • تواصل داخلي بين عشرات الخدمات بحمل عالٍ، وإنت متحكم باللغة والطرفين؟gRPC أسرع وأخف
  • محتاج Streaming حقيقي بالاتجاهين (زي تتبع حالة لحظي)؟gRPC مدعوم أصلًا بلا حلول جانبية

الخلاصة

مافي "أفضل" مطلق هون — كتير أنظمة إنتاجية حقيقية بتستخدم الاثنين مع بعض: gRPC للتواصل الداخلي الكثيف بين الخدمات، وREST (عبر API Gateway) للواجهة يلي بتوصل للعالم الخارجي والمتصفح.

ابدأ مسار المايكروسيرفيس الكامل بالعربي — أو شوف درس gRPC بالتفصيل.

📚 مصادر رسمية للتعمّق: freeCodeCamp — مصدر تعلّم البرمجة

الأسئلة الشائعة

هل gRPC بيلغي الحاجة لـ REST؟

لا. الاثنين بيتعايشوا بنفس النظام غالبًا — REST للـ API العام يلي المتصفح أو عملاء خارجيين بيتعاملوا معه مباشرة، وgRPC للتواصل الداخلي الكثيف بين خدماتك يلي إنت متحكم بطرفيه (Client وServer) بنفس الوقت.

ليش ما فيني أنادي خدمة gRPC مباشرة من كود JavaScript بالمتصفح؟

لأن المتصفح ما بيعطي JavaScript صلاحية التحكم بإطارات HTTP/2 الخام ولا بيعرض الـ trailers يلي gRPC محتاجها. الحل المتاح اسمه gRPC-Web، وهو طبقة وسيطة (عادة عبر Envoy) بتترجم الاستدعاءات لصيغة يقدر المتصفح يتعامل معها.

هل gRPC أسرع من REST دائمًا؟

أسرع بمعظم الحالات بسبب الترميز الثنائي المضغوط (protobuf) واتصال HTTP/2 المُعاد استخدامه، بس الفرق بيصير محسوس فعليًا بالحمل العالي (آلاف الطلبات بالثانية بين خدمات داخلية). لطلب واحد بسيط بينك وبين متصفح، الفرق غالبًا مو ملحوظ للمستخدم.

اقرأ أيضًا

تصفّح كل المقالات في المدوّنة، أو ابدأ التعلّم من المسارات و خرائط الطريق.