فهم مفاهيم gRPC واستخداماته وأفضل الممارسات

بينما نتابع تطوير التطبيق، من بين الأشياء المختلفة، هناك شيء رئيسي واحد لا نقلق بشأنه كثيرًا: قوة الحوسبة. وذلك لأن ظهور مزودي الألواح السحابية جعلنا أقل قلقًا بشأن إدارة مراكز البيانات. كل شيء متاح في غضون ثوانٍ على النحو المطلوب. وهذا يؤدي إلى زيادة في حجم البيانات أيضًا. يتم توليد ونقل البيانات الضخمة باستخدام وسائل مختلفة في طلبات مفردة. 

مع زيادة حجم البيانات، أضيفت إليها نشاطات مثل التجميع، وفك التجميع، وتكاليف النقل. على الرغم من أننا لا نقلق بشأن موارد الحوسبة، إلا أن التأخير يصبح عبئًا. نحتاج إلى تخفيض النقل. تم تطوير العديد من بروتوكولات الرسائل في الماضي للتطرق إلى هذا الموضوع. كانت SOAP ثقيلة، و REST نسخة مختصرة ولكننا نحتاج إلى إطار أكثر كفاءة. هذا هو المكان الذي يأتي فيه الدعوات البرمجية النظرية — RPC.

في هذا المقال، سنتعرف على ما هو RPC، والتنفيذات المختلفة لـ RPC، مع التركيز على gRPC، وهو تنفيذ Google لـ RPC. سنقارن أيضًا بين REST و RPC ونفهم الجوانب المختلفة لـ gRPC، بما في ذلك الأمان، والأدوات، وغيرها الكثير.

ما هو RPC؟

RPC تعني الدعوات البرمجية النظرية. التعريف موجود في الاسم نفسه. تعني دعوات الإجراء ببساطة دعوات الوظائف/الأساليب؛ إنها كلمة “النظري” التي تحدث فرقًا كبيرًا. ماذا لو استطعنا إجراء دعوة وظيفية عن بعد؟

بكل بساطة، إذا كانت الدالة موجودة على الخادم ومن أجل استدعائها من الجانب العميل، هل يمكن تبسيط ذلك كما لو كان استدعاء دالة/طريقة على الجهاز المحلي؟ ما تفعله RPC في الأساس هو إعطاء الوهم للعميل بأنه يستدعي طريقة محلية، ولكن في الواقع، يستدعي طريقة على جهاز بعيد يختزل مهام الطبقة الشبكية. الجمال في هذا أن العقد يبقى قويًا وشفافًا (سنناقش هذا لاحقًا في المقالة).

الخطوات المتضمنة في مكالمة RPC:

تدفق تسلسلي لـ RPC

هذا ما يبدو عليه عملية REST النموذجية:

RPC تختزل العملية إلى ما يلي:

هذا لأن جميع التعقيدات المرتبطة بإرسال الطلب الآن مخفية عنا (سنناقش هذا في إنشاء التعليمات البرمجية). كل ما يجب أن نقلق بشأنه هو البيانات والمنطق.

gRPC: ماذا، لماذا، وكيف في ذلك

حتى الآن ناقشنا RPC، والذي يعني في الأساس استدعاء دالة/طريقة عن بعد – مما يمنحنا المزايا مثل “تحديد العقد الصارم“، “تجنب نقل وتحويل البيانات”، “تخفيض اللاتنسية”، وهلم جرا، والتي سنناقشها أثناء متابعة هذه المشاركة. ما نود حقًا الغوص فيه هو إحدى إطارات تنفيذ RPC. RPC هو مفهوم و gRPC هو إطار عمل يعتمد عليه.

هناك تنفيذات مختلفة لـ RPCs. وهي:

• gRPC (جوجل)

• Thrift (Facebook)

• Finalge (Twitter)

نسمي نسخة Google من RPC بـ gRPC. تم تقديمه في عام 2015 وتزايد استخدامه منذ ذلك الحين. هو أحد أكثر آليات الاتصال اختيارًا في هيكل ميكروسرفيس.

يستخدم gRPC بروتوكول بافلز (شكل رسائل مفتوح المصدر) كطريقة افتراضية للتواصل بين العميل والخادم. أيضًا ، يستخدم gRPC HTTP/2 كبروتوكول افتراضي. هناك أربعة أنواع من الاتصالات التي يدعمها gRPC:

• أحادي الاتصال [الاتصال النموذجي بين العميل والخادم]

• تيار العميل 

• تيار الخادم

• تيار ترحيل ثنائي الاتجاه

بالانتقال إلى تنسيق الرسالة الذي يستخدم على نطاق واسع في gRPC – بروتوكول بروتوباف، والمعروف أيضاً بـ protobufs. تبدو رسالة protobufs بشكل ما يلي:

هنا، ‘Person’ هي الرسالة التي نود نقلها (كجزء من الطلب/الاستجابة) والتي تحتوي على حقول ‘name’ (نوع سلسلة)، ‘id’ (نوع سلسلة) و ’email’ (نوع سلسلة). الأرقام 1,2,3 تمثل موضع البيانات (كما في ‘name’، ‘id’، و ‘has_ponycopter’) عندما يتم تجاوزها إلى التنسيق الثنائي.

بمجرد إنشاء المطور ملف (الملفات) Protocol Buffer بكل الرسائل، يمكننا استخدام مُحوِّل بروتوكول باف (ملف ثنائي) لترجمة ملف البروتوكول المكتوب، مما سيولد جميع الفئات والأساليب العملية اللازمة للعمل مع الرسالة. على سبيل المثال، كما هو موضح هنا، ستبدو الشفرة المولدة (اعتمادًا على اللغة المختارة) مثل هذا.

كيف نعرّف الخدمات؟

نحن بحاجة إلى تعريف الخدمات التي تستخدم الرسائل أعلاه ليتم إرسالها/استقبالها.

بعد كتابة الأنواع اللازمة من الرسائل الطلب والاستجابة، الخطوة التالية هي كتابة الخدمة نفسها.

تُعرّف خدمات gRPC أيضًا في Protocol Buffers وهي تستخدم مفتاحي الكلمات “service” و”RPC” لتعريف خدمة.

انظر إلى محتوى ملف proto التالي:

هنا، HelloRequest وHelloResponse هي الرسائل وHelloService يعرض جهاز RPC واحد يسمى SayHello يأخذ HelloRequest كمدخل ويعطي HelloResponse كمخرج.

كما ذكرنا سابقًا، HelloService حاليًا يحتوي على مكالمة RPC واحدة فردية. ولكن يمكن أن يحتوي على أكثر من مكالمة RPC واحدة. أيضًا، يمكن أن يحتوي على مجموعة متنوعة من المكالمات RPC (فردية/تيارة من العميل/تيارة من الخادم/ثنائية الاتجاه).

لتحديد مكالمة RPC تيارة، كل ما عليك فعله هو وضع سلسلة ‘stream ‘ قبل الوسيطة الطلب/الاستجابة، تعريفات proto لمكالمات RPC التي تتدفق، والكود المولد.

في رابط قاعدة الكود أعلاه:

• streaming.proto: هذا الملف معرف من قبل المستخدم

• streaming.pb.go & streaming_grpc.pb.go: هذه الملفات تولد تلقائيًا عند تشغيل أمر مُجمّع البروتو.

gRPC مقابل REST

لقد تحدثنا بشكل كافٍ عن gRPC. وذكر أيضًا REST. ما فاتنا هو مناقشة الفرق. أعني، بما أن لدينا إطار عمل للاتصال خفيف الوزن ومثبت بقوة في شكل REST، فلماذا احتجنا للبحث عن إطار عمل اتصال آخر؟ دعونا نفهم المزيد عن gRPC مقابل REST، مع الجوانب الإيجابية والسلبية لكل منهما.

من أجل المقارنة، نحتاج إلى معايير. لذا دعونا نقسم المقارنة إلى المعايير التالية:

• تنسيق الرسائل: بروتوكول بروتوباف ضد JSON

  • سرعة التحويل وفك التحويل في حالة بروتوكول بروتوباف أفضل بكثير عبر جميع أحجام البيانات (صغيرة/متوسطة/كبيرة). نتائج اختبار الموازنة. 

  • بعد التحويل، JSON قابل للقراءة بشكل إنساني بينما بروتوباف (بتنسيق ثنائي) ليس كذلك. لست متأكدا إذا كان هذا عيبًا أم لا لأنك أحيانًا تود أن ترى تفاصيل الطلب في أداة مطوري جوجل أو مواقع Kafka وفي حالة بروتوباف لا يمكنك فهم أي شيء. 

• بروتوكول الاتصال: HTTP 1.1 مقابل HTTP/2T

  • يعتمد REST على HTTP 1.1؛ الاتصال بين عميل REST وخادم يتطلب توصيل TCP معلق يشمل تحديث ثلاثي. عندما نتلقى ردًا من الخادم بعد إرسال طلب من العميل، لا يكون التوصيل TCP موجودًا بعد ذلك. يحتاج إلى تشغيل توصيل TCP جديد من أجل معالجة طلب آخر. تضيف تكوين توصيل TCP في كل طلب إلى تأخير التنفيذ.

  • لذا واجهت gRPC التي تعتمد على HTTP 2 هذه التحديات من خلال وجود اتصال دائم. يجب أن نتذكر أن الاتصالات الدائمة في HTTP 2 تختلف عن تلك الموجودة في الويب سوكس حيث يتم استغلال توصيل TCP ويتم نقل البيانات بلا مراقبة. في اتصال gRPC، بمجرد إنشاء توصيل TCP، يتم إعادة استخدامه لعدة طلبات. يتم توصيل جميع الطلبات من نفس العميل والخادم على نفس توصيل TCP.

• فقط نتركد بشأن البيانات والمنطق: توليفة التعليمات البرمجية هي المواطن الأول

  • تتمثل ميزات توليفة التعليمات البرمجية في gRPC من خلال مُعالج protoc المُدمج فيه. مع واجهات برمجة التطبيقات REST، من الضروري استخدام أداة خارجية مثل Swagger لتلقائية توليف التعليمات البرمجية لمكالمات API بلغات مختلفة.

  • في حالة gRPC، يخفّف عن عملية التجميع/التفكيك، إعداد الاتصال، وإرسال/استقبال الرسائل؛ ما نحتاج القلق إليه هو البيانات التي نرغب في إرسالها أو استقبالها والمنطق.

• سرعة التحويل

  • نظرًا لأن التنسيق الثنائي أخف بكثير من تنسيق JSON، فإن سرعة التحويل في حالة gRPC أسرع بسبع إلى عشر مرات من REST.

مرة أخرى، في الوقت الراهن، لا يوفر gRPC دعمًا للمتصفحات حيث أن معظم إطارات الواجهة لا تزال تعتمد دعمًا محدودًا أو عدم دعم gRPC. على الرغم من أن gRPC هو الخيار التلقائي في معظم الحالات عندما يتعلق الأمر بالتواصل بين الخدمات الداخلية المجزأة، إلا أن الأمر ليس كذلك بالنسبة للتواصل الخارجي الذي يتطلب تكامل الواجهة.

الآن بعد أن قمنا بمقارنة كلا الإطارين: gRPC و REST. أيهما يجب استخدامه ومتى؟

• في تصميم الميكروسرفيس به العديد من الخدمات المجزأة الخفيفة، حيث يكون أهمية نقل البيانات أمرًا حاسمًا، فإن gRPC سيكون الخيار المثالي.

• إذا كان توليد الكود مع دعم لغات متعددة هو متطلب، فإن gRPC يجب أن يكون الإطار المستخدم.

• بفضل قدرات gRPC في البث المباشر، فإن التطبيقات الحية مثل التداول أو OTT ستستفيد منه بدلاً من استخدام REST للتأكد باستمرار.

• إذا كانت النطاق الترددي هو القيد، فإن gRPC سيوفر تأثيرًا أقل في التأخير والناتج.

• إذا كان التطوير السريع والتكرار عالي السرعة هو متطلب، فإن REST يجب أن يكون الخيار المستخدم.

مفاهيم gRPC

توزيع الحمل

على الرغم من أن الاتصال الدائم يحل مشكلة التأخير، إلا أنه يثير تحديًا آخر يتمثل في توزيع الحمل. نظرًا لأن gRPC (أو HTTP2) يخلق اتصالات دائمة، حتى بوجود موزع الحمل، يشكل العميل اتصالًا دائمًا مع الخادم الموجود خلف موزع الحمل. هذا يشبه جلسة لزومية.

يمكننا فهم المشكلة أو التحدي من خلال مثال توضيحي. وتوجد الشفرة وملفات النشر في الموقع التالي: https://github.com/infracloudio/grpc-blog/tree/master/grpc-loadbalancing.

من قاعدة التعليمات البرمجية للعرض التوضيحي أعلاه، يمكننا معرفة أن مسؤولية موزع الحمل تقع على العميل. وهذا يؤدي إلى حقيقة أن مزايا gRPC، أي الاتصال الدائم، لا تكمن بهذا التغيير. ولكن يمكن استخدام gRPC مع خيراته الأخرى.

اقرأ المزيد عن موزع الحمل في gRPC.

في قاعدة التعليمات البرمجية للعرض التوضيحي أعلاه، يتم استخدام/عرض استراتيجية موزع الحمل الموزع بالتعادل فقط. ولكن gRPC يدعم استراتيجية أخرى لموزع الحمل على العميل تسمى “الاختيار الأول”.

علاوة على ذلك، يدعم العميل المخصص موزع الحمل.

عقد نظيف

في REST، يتم توثيق العقد بين العميل والخادم ولكنه ليس صارمًا. إذا عدنا إلى أبعد من ذلك إلى SOAP، كانت العقود تتعرض عبر ملفات wsdl. في REST نعرض العقود عبر Swagger ومرافق أخرى. ولكن الصرامة في ذلك تفتقر، لا يمكننا التأكد بالتأكيد ما إذا كان العقد قد تغير على جانب الخادم أثناء تطوير شفرة العميل.

مع gRPC، العقد إما عبر ملفات proto أو التوجيه الموجه من ملفات proto مشترك مع كل من العميل والخادم. هذا مثل إجراء دالة استدعاء ولكن عن بُعد. ونظرًا لأننا نجري دالة استدعاء، نعرف تمامًا ما نحتاج إلى إرساله وما الذي نتوقعه كرد فعل. تعتبر تعقيدات إجراء الاتصالات مع العميل، والعناية بالأمان، والتجليد-فك التجليد، إلخ ، مجردة. كل ما نهتم به هو البيانات.

النظر في قاعدة التعليمات البرمجية التالية:

https://github.com/infracloudio/grpc-blog/tree/master/greet_app     

يستخدم العميل التوجيه (التعليمات البرمجية الموجهة من ملف proto) لإنشاء كائن عميل واستدعاء دالة عن بُعد: 

```sh

import greetpb "github.com/infracloudio/grpc-blog/greet_app/internal/pkg/proto"



cc, err := grpc.Dial(“<server-address>”, opts)

if err != nil {

    log.Fatalf("could not connect: %v", err)

}



c := greetpb.NewGreetServiceClient(cc)



res, err := c.Greet(context.Background(), req)

if err != nil {

    log.Fatalf("error while calling greet rpc : %v", err)

}

```

وبالمثل، يستخدم الخادم أيضًا نفس التوجيه (التعليمات البرمجية الموجهة من ملف proto) لاستلام كائن الطلب وإنشاء كائن الاستجابة: 

```sh

import greetpb "github.com/infracloudio/grpc-blog/greet_app/internal/pkg/proto"



func (*server) Greet(_ context.Context, req *greetpb.GreetingRequest) (*greetpb.GreetingResponse, error) {

 

  // افعل شيئًا مع 'req'

 

   return &greetpb.GreetingResponse{

    Result: result,

      }, nil

}

```

كلاهما يستخدم التوجيه المشترك الذي تم إنشاؤه من ملف proto الموجود هناك.

و تم إنشاء البط stub باستخدام أمر مُجمّع proto الآتي. 

```sh

protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative internal/pkg/proto/*.proto

```

الأمان

عمل التوكيد gRPC والتفعيل على مستويين:

• يتم التعامل مع التوكيد/التفعيل على مستوى المكالمة في العادة من خلال الأسلوب المُطبق في المعلومات عندما يتم إجراء المكالمة. مثال على التوكيد القائم على الأسلوب.

• يستخدم التوكيد على مستوى القناة شهادة العميل المُطبقة على مستوى الاتصال. يمكن أن يشمل أيضا التوكيد/التفعيل على مستوى المكالمة ليتم تطبيقها على كل مكالمة على القناة من قبل. مثال على التوكيد القائم على الشهادة.

يمكن استخدام أي من هذه الآليات أو كليهما لمساعدة الخدمات على الأمان.

نصف الخلية

في REST، نستخدم نصف الخلية لأغراض مختلفة مثل:

• تطبيق الحد الأقصى للطلبات

• التحقق من صحة الطلب/الاستجابة قبل/بعد

• معالجة التهديدات الأمنية

يمكننا تحقيق الشيء نفسه باستخدام gRPC أيضًا. المصطلحات تختلف في gRPC – يشار إليها باسم المقاطعات، لكنها تقوم بنشاطات مماثلة.

في فرع نصف الخلية من قاعدة ال kode ‘greet_app’، قمنا بدمج مقاطعات السجل و Prometheus. 

انظر كيف تم تكوين المقاطعات لاستخدام حزمة Prometheus والسجلات هنا.

لكن يمكننا دمج حزم أخرى في المقاطعات لأغراض مثل منع الذيل والاستعادة (للتعامل مع الاستثناءات)، التتبع، حتى التوثيق، وغير ذلك الكثير.

نصف الخلية المدعومة من إطار gRPC.

التعبئة، التوحيد الإصدار، وممارسات الكود للملفات Proto

التعبئة

فلنتبع فرع التعبئة المعبأة.

أولاً، ابدأ بملف ‘Taskfile.yaml’، المهمة ‘gen-pkg’ تنص على ‘protoc –proto_path=packaging packaging/*.proto –go_out=packaging’. وهذا يعني أن ‘protoc’ (مترجم البروتوكول) سيحول جميع ملفات ‘packaging/*.proto’ إلى ملفات ‘go’ المكافئة كما هو مبين بواسطة العلم ‘–go_out=packaging’ في الدليل ‘packaging’ نفسه.

ثانياً في ملف ‘processor.proto’، تم تعريف رسائلين هما ‘CPU’ و’GPU’. بينما يعتبر CPU رسالة بسيطة بثلاث حقول من الأنواع الأساسية للبيانات، فإن GPU من ناحية أخرى لديه نوع بيانات مخصص يسمى ‘Memory’. ‘Memory’ هي رسالة منفصلة ويتم تعريفها في ملف منفصل بذاته.

إذن كيف تستخدم رسالة ‘Memory’ في ملف ‘processor.proto’؟ باستخدام استيراد.

حتى إذا حاولت توليد ملف proto بتشغيل المهمة ‘gen-pkg’ بعد ذكر الاستيراد، ستطرح خطأ. حيث يفترض ‘protoc’ بشكل افتراضي أن كلا الملفين ‘memory.proto’ و’processor.proto’ في حزم مختلفة. لذا تحتاج إلى ذكر نفس اسم الحزمة في كلا الملفين.

يشير الإعداد الاختياري ‘go_package’ إلى أن المترجم يجب أن يخلق اسم حزمة ‘pb’ لملفات go. إذا كان لتوليد ملفات proto من لغة أخرى، سيكون اسم الحزمة ‘laptop_pkg’.

الإصدارات

• يمكن أن يكون هناك نوعان من التغييرات في gRPC تغييرات كسرية وغير كسرية.

• التغييرات غير الكسرية تشمل إضافة خدمة جديدة، إضافة ميثود جديدة إلى خدمة، إضافة حقل إلى بروتو للطلب أو الاستجابة، وإضافة قيمة إلى تعداد

• التغييرات الكسرية مثل إعادة تسمية حقل، تغيير نوع بيانات الحقل، رقم الحقل، إعادة تسمية أو إزالة الحزمة، الخدمة أو الأساليب تتطلب توفير إصدارات الخدمات

• اختياري التعبئة.

ممارسات الكود 

• يجب أن يضاف الطلب برسالة تتبع بـ request `CreateUserRequest`

• يجب أن يضاف الاستجابة برسالة تتبع بـ request `CreateUserResponse`

• في حالة وجود رسالة استجابة فارغة، يمكنك استخدام كائن فارغ `CreateUserResponse` أو استخدام `google.protobuf.Empty`

• يجب أن يكون اسم الباكج منطقيًا ويجب أن يكون معدلًا، على سبيل المثال: باكج `com.ic.internal_api.service1.v1`

أدوات

تدعم بيئة gRPC مجموعة من الأدوات لتسهيل الأمور في المهام غير التطويرية مثل الوثائق، بوابة REST لخادم gRPC، دمج الموافقين المخصصين، التحقق من الأخطاء، إلخ. فيما يلي بعض الأدوات التي يمكن أن تساعدنا في تحقيق ذلك:

• protoc-gen-grpc-gateway — إضافة لإنشاء بوابة REST API لـ gRPC. إنها تسمح بنقاط gRPC كنقاط API REST وتقوم بترجمة من JSON إلى proto. في الأساس، تعرّف خدمة gRPC ببعض التعليقات المخصصة وتجعل تلك الطرق المتعلقة بـ gRPC قابلة للوصول عبر REST باستخدام طلبات JSON.

• protoc-gen-swagger — و-إضافة رفيقة لـ grpc-gateway. يمكنه إنشاء ملف swagger.json بناءً على التعليمات البرمجية المخصصة المطلوبة لبوابة gRPC. بعد ذلك، يمكنك استيراد هذا الملف إلى عميل REST المفضل لديك (مثل Postman) وإجراء مكالمات API REST إلى الطرق التي قمت بتعريفها.

• protoc-gen-grpc-web — إضافة تمكن الجانب الأمامي لدينا من التواصل مع الخلفية باستخدام مكالمات gRPC. سيأتي مقال منفصل حول هذا في المستقبل.

• protoc-gen-go-validators — عبارة عن ملحق يسمح بتحديد قواعد التحقق من صحة لحقول الرسائل البروتو ​​. يولد طريقة خطأ Validate() لرسائل proto يمكنك استدعاؤها في GoLang للتحقق مما إذا كانت الرسالة مطابقة لتوقعاتك المسبقة المحددة.

• https://github.com/yoheimuta/protolint — ملحق لإضافة قواعد البرنامج النصي الموجه إلى ملفات proto

تجربة باستخدام POSTMAN

على عكس اختبار واجهات برمجة التطبيقات REST باستخدام postman أو أي أدوات مماثلة مثل Insomnia، ليس مريحًا تمامًا لاختبار خدمات gRPC.

الملاحظة: يمكن اختبار خدمات gRPC أيضًا من واجهة الأوامر باستخدام أدوات مثل evans-cli. ولكن من أجل ذلك، يحتاج التأكيد (إذا لم يكن مفعلًا فإن المسار إلى ملف proto مطلوب ) إلى تمكين التأكيد في خوادم gRPC. التغييرات التي يجب إجراؤها من أجل تمكين التأكيد وكيفية الدخول إلى وضع تفاعلي repl في evans-cli. بعد دخول وضع تفاعلي repl في evans-cli، يمكن اختبار خدمات gRPC من واجهة الأوامر بحد ذاتها ويوصف العملية في صفحة github لـ evans-cli.

Postman لديها نسخة تجريبية لاختبار خدمات gRPC.

فيما يلي خطوات كيف يمكنك القيام بذلك:

1. افتح Postman

2. انتقل إلى ‘APIs’ في الشريط الجانبي الأيسر

3. انقر على علامة ‘+’ لإنشاء API جديد:

4. في نافذة البوب أب، أدخل ‘الاسم’، ‘الإصدار’، و’تفاصيل المخطط’ وانقر على إنشاء [إلا إذا كنت بحاجة إلى الاستيراد من مصادر مثل github/bitbucket]. هذه الخطوة ذات صلة إذا كنت ترغب في نسخ لصق عقد proto.

5. يتم إنشاء API الخاص بك كما هو موضح أدناه. انقر على الإصدار ‘1.0.0’ ، انتقل إلى التعريف وأدخل عقد proto الخاص بك.

6. تذكر أن الاستيراد لا يعمل هنا ، لذا من الأفضل الاحتفاظ بجميع protos التابعة في مكان واحد.

7. ستساعدك الخطوات المذكورة أعلاه في الاحتفاظ بالعقود للاستخدام في المستقبل.

8. ثم انقر على ‘جديد’ وحدد ‘طلب gRPC’:

9. أدخل URI واختر proto من قائمة الAPIs المحفوظة:

10. أدخل رسالة الطلب الخاصة بك وانقر على ‘استدعاء’:

في الخطوات المذكورة أعلاه، توصلنا إلى طريقة اختبار APIs gRPC لدينا عبر POSTMAN. عملية اختبار النقاط نهاية gRPC تختلف عن تلك الخاصة بنقاط نهاية REST باستخدام POSTMAN. من المهم تذكر أنه عند إنشاء وحفظ عقد proto كما في #5، يجب أن تكون جميع تعريفات الرسائل proto والخدمات في نفس المكان. لأنه لا يوجد توفير للوصول إلى رسائل proto عبر الإصدارات في POSTMAN.

الخاتمة

في هذا المنشور، طورنا فكرة حول RPC، ورسمنا مقارنات مع REST ومناقشة إختلافاتهما، ثم تحدثنا عن تنفيذ RPC، أي gRPC الذي طورته جوجل. 

يمكن أن يكون gRPC كإطار عمل حاسمًا خاصة بالهياكل القائمة على الخدمات المتكاملة للتواصل الداخلي. يمكن استخدامه للتواصل الخارجي أيضًا ولكنه سيتطلب بوابة REST. gRPC ضروري للتطبيقات التي تستخدم البث والتطبيقات الحية في الوقت الفعلي. 

الطريقة التي يثبت بها Golang نفسه كلغة برمجة تنفيذية على الخادم، يثبت gRPC نفسه كإطار تواصل قائم.