grpcurl هو أداة سطر الأوامر المفضلة للتفاعل مع خدمات gRPC، لكن أمر المحطة الطرفية الغني بالأعلام ليس دائمًا أسرع طريقة لاستكشاف واجهة برمجة تطبيقات (API)، أو إعادة تشغيل مكالمات التدفق، أو مشاركة طلب مع زميل في الفريق. إذا كنت تريد عميل gRPC مرئيًا أو أداة تفعل أكثر من استدعاء طريقة واحدة في كل مرة، يقدم هذا الدليل ستة بدائل لـ grpcurl، سواء كانت واجهات رسومية (GUI) أو سطر أوامر (CLI)، مع ملاحظات صريحة حول ما يناسبه كل واحد منها.
ما هو grpcurl وأين يتوقف
grpcurl هو أداة curl لـ gRPC. توجّهها إلى خادم، وتُسمي خدمة وطريقة، وتمرر نص طلب JSON، ثم تُعيد الاستجابة. تدعم الأداة انعكاس الخادم (server reflection)، لذا يمكنها سرد الخدمات والطرق دون الحاجة إلى تسليمها ملف .proto، وتعمل مع TLS ورؤوس البيانات الوصفية (metadata headers) وواصفات .proto أو protoset عندما يكون الانعكاس معطلاً.
يغطي ذلك الكثير. لفحص سريع للحالة أو مكالمة مبرمجة في CI، يصعب التغلب على grpcurl. إليك حيث يصبح الأمر محرجًا:
- إنه يعمل عبر سطر الأوامر فقط (CLI-only). كل مكالمة هي أمر، واستكشاف واجهة برمجة تطبيقات غير مألوفة يعني قراءة قوائم الطرق في المحطة الطرفية وكتابة JSON يدويًا.
- التدفق غير عملي. يمكن لـ grpcurl إجراء تدفق من العميل والخادم والتدفق ثنائي الاتجاه، ولكنك تغذي الرسائل كتدفق من JSON عبر stdin. لا توجد طريقة مرئية لمشاهدة تدفق الخادم يصل رسالة تلو الأخرى.
- الطلبات لا يتم حفظها. لا توجد مجموعة مدمجة، أو سجل، أو تبديل للبيئة. تدير ذلك بنفسك باستخدام نصوص shell أو ملف ملاحظات.
- المشاركة تعني مشاركة سلسلة أوامر. لا توجد مساحة عمل مشتركة، ولا أمثلة محفوظة يمكن لزميل في الفريق فتحها وتشغيلها.
لا شيء من ذلك يجعل grpcurl سيئًا. إنه يجعله أداة ضيقة النطاق. إذا تجاوز عملك المكالمات المبرمجة الفردية، فإن أحد الخيارات أدناه سيكون أكثر ملاءمة.
بدائل grpcurl بلمحة
| الأداة | الواجهة | دعم التدفق | الانعكاس | الأفضل لـ |
|---|---|---|---|---|
| Apidog | واجهة رسومية (سطح المكتب) | أحادي + خادم، عميل، ثنائي الاتجاه | نعم | اختبار gRPC المرئي جنبًا إلى جنب مع REST وGraphQL والوثائق |
| grpcui | واجهة ويب | أحادي + تدفق | نعم | واجهة متصفح لـ grpcurl، من نفس المؤلف |
| Postman | واجهة رسومية (سطح المكتب/الويب) | أحادي + تدفق | نعم | الفرق التي اعتمدت Postman بالفعل |
| Kreya | واجهة رسومية (سطح المكتب) | أحادي + تدفق | نعم | عميل سطح مكتب مخصص لـ gRPC وREST |
| Evans | سطر أوامر تفاعلي | أحادي + تدفق | نعم | سير عمل محطة طرفية بأسلوب REPL |
| BloomRPC | واجهة رسومية (سطح المكتب) | أحادي + تدفق | محدود | للمشاريع القديمة فقط (غير مدعوم) |
1. Apidog (عميل gRPC المرئي)
Apidog هي منصة API تتعامل مع REST وGraphQL وWebSocket وSOAP وgRPC في تطبيق سطح مكتب واحد، لذلك يجلس gRPC بجانب بقية عملك على واجهة برمجة التطبيقات بدلاً من أن يكون في محطة طرفية منفصلة. لـ gRPC على وجه التحديد، يمكنك استيراد ملف .proto أو الاتصال عبر انعكاس الخادم، ويقوم Apidog بقراءة تعريفات الخدمة والطرق لك.
من هناك تحصل على منشئ طلبات قائم على النماذج. تظهر الطرق في قائمة يمكنك النقر عليها، وتُعرض رسائل الطلب كحقول قابلة للتعديل بناءً على مخطط proto، وتعود الاستجابات منسقة. تعمل جميع أنواع مكالمات gRPC الأربعة: أحادية، تدفق الخادم، تدفق العميل، والتدفق ثنائي الاتجاه. بالنسبة لتدفق الخادم، يمكنك مشاهدة الرسائل تهبط في لوحة الاستجابة عند وصولها، وهو الجزء الذي يجعلك grpcurl تحدق فيه عبر الإخراج القياسي (stdout).
نطاق صادق: Apidog هو عميل gRPC بواجهة رسومية (GUI)، وليس بديلاً مباشرًا لـ grpcurl عبر سطر الأوامر (CLI). إذا كانت حاجتك الحقيقية هي أداة قابلة للبرمجة يمكنك إدراجها في مسار Shell، فإن grpcurl أو Evans يبقى أقرب إلى هذا الشكل. حيث يتفوق Apidog هو في الاستكشاف، والطلبات المحفوظة، ومتغيرات البيئة لنقاط النهاية والبيانات الوصفية، والحفاظ على gRPC في نفس مساحة العمل مثل بروتوكولاتك الأخرى. إذا كنت تبني خدمات عبر بروتوكولات متعددة، فإن سير عمل واجهة برمجة التطبيقات متعددة البروتوكولات يكون أكثر سلاسة عندما تغطي أداة واحدة جميعها.
قم بتنزيل Apidog لاستيراد ملف .proto وتشغيل أول مكالمة تدفق لك في واجهة رسومية.
2. grpcui
تأتي grpcui من نفس مؤلف grpcurl، fullstorydev، وهي الخطوة الطبيعية التالية إذا كنت تحب grpcurl ولكنك تريد واجهة مرئية. تقوم بتشغيل خادم ويب محلي يوفر لك نموذجًا في المتصفح لاستدعاء طرق gRPC. تحصل على قوائم منسدلة للخدمات والطرق، وحقول نماذج مُولَّدة لرسائل الطلب، ومدخلات بيانات وصفية، وكل ذلك مدعوم بانعكاس الخادم أو واصفات proto.
تدعم الأداة التدفق وتعكس نفس مجموعة ميزات gRPC التي تتوقعها من عائلة grpcurl. المفاضلة هي أن grpcui أحادية الغرض. إنها مستكشف gRPC ولا شيء آخر، لذلك لا يوجد اختبار REST، ولا مجموعات محفوظة عبر الجلسات، ولا مساحة عمل للفريق. إذا كنت تريد واجهة مستخدم سريعة في المتصفح فوق خادم واحد، فهي مناسبة تمامًا. يحتوي مستودع grpcui على تفاصيل الإعداد.
3. Postman
أضاف Postman دعم gRPC، وإذا كان فريقك يستخدم Postman بالفعل، فإن الأمر يستحق استخدامه قبل إضافة أداة أخرى. يمكنك إنشاء طلب gRPC، وتوجيهه إلى خادم، وتحميل ملف .proto (أو استخدام خادم يدعم الانعكاس)، واستدعاء الطرق عبر واجهة مستخدم Postman. يتعامل مع المكالمات الأحادية والمكالمات المتدفقة، ويسمح لك بتعيين البيانات الوصفية والترخيص، ويحفظ الطلبات في مجموعات مثل بقية عملك في Postman.
المميزات حقيقية: المجموعات، البيئات، ومساحة العمل التي يعرفها فريقك بالفعل. الصعوبة هي أن دعم gRPC في Postman قد تأخر تاريخياً عن تجربة REST الخاصة به من حيث الصقل، وتأتي حسابات Postman الأثقل مع اعتبارات مزامنة سحابية وتسعير يفضل بعض الفرق تجنبها. إذا كنت تقيّم الأداة الأوسع، فراجع مجموعتنا من بدائل Postman لاختبار واجهات برمجة التطبيقات. يغطي توثيق gRPC الخاص بـ Postman مجموعة الميزات الحالية.
4. Kreya
Kreya هو عميل سطح مكتب يركز على gRPC وREST. يقرأ ملفات .proto ويدعم انعكاس الخادم، وينشئ نماذج طلبات من مخططك، ويتعامل مع جميع أوضاع التدفق. يعتمد على تصميم نظيف قائم على المشاريع حيث تنظم المكالمات، وتعيّن البيئات، وتعيد استخدام المتغيرات، مما يجعله اختيارًا قويًا إذا كنت تريد واجهة رسومية مخصصة لـ gRPC دون الحاجة إلى منصة كاملة حولها.
إنه أخف نطاقًا من منصة API كاملة، لذلك لن تجد فيه أدوات المحاكاة (mocking)، أو إنشاء التوثيق، أو أدوات التصميم. للمطورين الذين يحتاجون بشكل أساسي إلى استكشاف واختبار خدمات gRPC بواجهة أنيقة، فإن هذا التركيز يعتبر ميزة، وليس نقصًا.
5. Evans
Evans هو عميل gRPC تفاعلي يعمل في محطتك الطرفية ولكنه يتصرف أشبه بـ REPL أكثر من كونه أمرًا لمرة واحدة. تبدأ جلسة، ويسمح لك Evans بتصفح الحزم والخدمات والطرق، ثم بناء وإرسال الطلبات بشكل تفاعلي. يدعم انعكاس الخادم وملفات .proto، ويتعامل مع التدفق، ويبقيك في موجه إرشادي بدلاً من إجبارك على تذكر كل علامة.
إذا كنت تريد الإحساس الأصلي لـ grpcurl في المحطة الطرفية ولكنك تكره إعادة كتابة الاستدعاءات الطويلة، فإن Evans هو الحل الوسط. لا يزال أداة سطر أوامر (CLI)، لذا لا يوجد عرض تدفق مرئي ولا مساحة عمل مشتركة، لكن الوضع التفاعلي يزيل الكثير من تعقيدات grpcurl. يحتوي مستودع Evans على GitHub على تعليمات التثبيت.
6. BloomRPC (للأنظمة القديمة فقط)
كان BloomRPC ذات يوم واجهة المستخدم الرسومية مفتوحة المصدر الشهيرة لـ gRPC، وهو تطبيق سطح مكتب مزود بمستكشف طرق ومحرر طلبات. لا يزال يُذكر في الأدلة القديمة، لذا يستحق الذكر، لكن المشروع لم يعد مدعومًا بنشاط. هذا يعني أن ميزات gRPC الأحدث، وتحديثات التبعيات، وإصلاحات توافق نظام التشغيل لا تصل إليه.
لا تختر BloomRPC لمشروع جديد. إذا ورثت سير عمل مبني عليه، فخطط للانتقال إلى أحد الخيارات المدعومة المذكورة أعلاه. ندرجه هنا فقط لكي تعرف ما هو ولماذا لم يعد توصية حالية.
كيف تختار
طابق الأداة مع طريقة عملك الفعلية:
- إذا كنت تريد عميل gRPC مرئيًا مع تدفق يمكنك مشاهدته وطلبات يمكنك حفظها ومشاركتها: Apidog.
- إذا كنت تحب grpcurl وتريد نموذج متصفح فوقه: grpcui.
- إذا كان فريقك قد اعتمد Postman بالفعل: دعم gRPC في Postman.
- إذا كنت تريد عميل سطح مكتب مخصصًا لـ gRPC وREST: Kreya.
- إذا كنت تريد البقاء في المحطة الطرفية ولكنك ترغب في التخلص من تعب الأعلام: Evans.
- إذا كنت تحافظ على إعداد قديم: اعلم أن BloomRPC غير مدعوم وخطط للهجرة.
إذا كنت تختبر gRPC من البداية إلى النهاية وتريد استعراضًا شاملاً طريقة بطريقة، فإن دليلنا حول كيفية اختبار واجهات برمجة تطبيقات gRPC بكفاءة يغطي سير العمل بعمق، ويبقى الدليل الأصلي لـ grpc-curl نقطة البداية الصحيحة إذا كنت ملتزمًا بسطر الأوامر.
الأسئلة الشائعة
هل توجد نسخة رسومية (GUI) من grpcurl؟
grpcui، من نفس المؤلف، هو أقرب واجهة رسومية مباشرة: فهو يضع نموذجًا في المتصفح فوق نفس معالجة الانعكاس والبروتوكول التي يستخدمها grpcurl. إذا كنت تريد تطبيق سطح مكتب كاملاً مع طلبات محفوظة، وبيئات، وتدفق يمكنك مشاهدته بصريًا، فإن Apidog يغطي gRPC جنبًا إلى جنب مع REST وGraphQL في عميل واحد.
هل يمكنني اختبار تدفق gRPC بدون سطر الأوامر؟
نعم. تدعم Apidog وPostman وKreya وgrpcui جميعها تدفق gRPC عبر واجهة مستخدم، بما في ذلك تدفق الخادم حيث يتم عرض الرسائل عند وصولها. يمكن لـ grpcurl وEvans أيضًا بث التدفق، لكنهما يغذيان ويعرضان الرسائل كنص طرفي بدلاً من لوحة مرئية.
هل تحتاج هذه الأدوات إلى ملف proto.؟
ليس دائمًا. تدعم كل أداة هنا انعكاس خادم gRPC، لذا إذا كان خادمك يكشف عن الانعكاس، يمكن للعميل اكتشاف الخدمات والطرق بنفسه. عندما يكون الانعكاس متوقفًا، يمكنك توفير ملف .proto أو مجموعة protoset مجمعة، ومعظم هذه الأدوات تقبل كليهما. للحصول على صورة اختبار أوسع، يشرح الدليل النهائي لاختبار واجهات برمجة التطبيقات مكانة gRPC بين REST والبروتوكولات الأخرى.
هل grpcurl لا يزال يستحق الاستخدام؟
بالتأكيد، للوظيفة المناسبة. grpcurl ممتاز للمكالمات المبرمجة، وفحوصات CI، والاستدعاءات السريعة لمرة واحدة من المحطة الطرفية. البدائل هنا تهم عندما تتجاوز الأوامر الفردية وترغب في الاستكشاف المرئي، والمجموعات المحفوظة، والتدفق القابل للمشاهدة، أو مساحة عمل مشتركة للفريق.
الخاتمة
grpcurl هو أداة قوية لـ gRPC عبر سطر الأوامر، ولا شيء هنا يحل محله للمكالمات المبرمجة والأصلية للمحطة الطرفية. ما يتغير هو المهمة. بمجرد أن تستكشف خدمات غير مألوفة، أو تشاهد التدفقات، أو تشارك الطلبات مع فريق، فإن العميل المرئي يوفر وقتًا حقيقيًا. من بين خيارات الواجهة الرسومية (GUI)، يبرز Apidog لأنه يجمع gRPC وREST وGraphQL والمحاكاة (mocking) والوثائق في مكان واحد، بحيث لا يكون اختبار gRPC الخاص بك معزولًا.
هل تريد اختبار خدمة gRPC دون كتابة علامة واحدة؟ جرّب Apidog مجانًا، استورد ملف .proto الخاص بك أو اتصل عبر الانعكاس، وقم بتشغيل المكالمات الأحادية والمتدفقة في واجهة رسومية في دقائق.