المقدمة

الـ gRPC هي اختصار لـ Google Remote Procedure Call وهي تكنولوجيا بتخلي الـ Service تقدر تنادي الـ function اللي موجودة في Service تانية كأنها بتناديها عادي كـ Function Call، حتى لو الـ Service التانية دي مكتوبة بلغة برمجة مختلفة ومش موجودة على نفس الـ Machine!

بشكل أبسط يعني لو عندنا Service مكتوبة بـ Java و Service تانية مكتوبة بـ Python، نقدر نخلي الـ Python ينادي Function في الـ Java بسهولة.

في الـ Microservices لو كل Service بدأت تعمل Generate لـ Client Library عشان الـ Services التانية تستخدمها ، هنضطر نعمل Client Library بلغات برمجة مختلفة على حسب الـ Services التانية ، وده مش حاجة منطقية! وهنا بتيجي ميزة الـ gRPC في انها بتوفر Unified Framework وكمان Language Agnostic ، فاحنا بنقول ده الـ proto اللي عاوزها والـ Client بيستعمل الـ gRPC Framework في انه يبعتلنا الـ Proto ويستقبل الـ Proto كـ Response وخلاص.

الـ gRPC بيبدأ من الـ Schema ، بـ Define الـ APIs بتاعتي وبقول دول الـ Functions اللي عندي أو الـ Contracts بتاعتي ، وبحدد الـ Request/Response كـ proto واللي هي اختصار للـ Protocol Buffer.

الـ gRPC شغال إزاي؟

الـ gRPC بيعتمد على حاجة اسمها Protocol Buffers (Protobuf). دي زي JSON كده، بس أخف وأسرع، بتستخدمها علشان توصف شكل البيانات اللي رايحة واللي جاية.

فبدل ما نبعت JSON كبير ومليان تفاصيل، بنكتب ملف .proto نعرف فيه الـ Message والـ Functions اللي عاوزين نتبادلها بين الـ Client والـ Server.

فانا بقول عندي service x بتشمل الـ functions الآتية وكل function بتستقبل proto request وبترجع proto response وخلاص كده ، فمش محتاج باه احدد الـ params دي هتيجي من الـ query , url , body والـ complexity بتاعة الـ REST

مثال سريع على ملف .proto:

syntax = "proto3";

service KitchenService {
  rpc PrepareOrder (OrderRequest) returns (OrderResponse);
}

message OrderRequest {
  int32 order_id = 1;
  string meal = 2;
  string extra = 3;
}

message OrderResponse {
  bool ready = 1;
  string note = 2;
}

الـ compiler بعد كده بيطلع كود للـ (Client) والـ (Server) تلقائيًا بلغاتهم المكتوبة بيهم سواء Java / Go.

نقدر دلوقتي لو عندنا مثلًا DeliveryService بتنادي على الـ KitchenService يبقى عندنا حاجة شبه كده: