أفضل بديل لـ BloomRPC

كان BloomRPC هو الإجابة على سؤال يطرحه كل مطور gRPC في النهاية: "أين Postman الخاص بي لـ gRPC؟" قم بتحميل ملف .proto، واحصل على نص طلب JSON قابل للتحرير، ثم اضغط على إرسال. كان الأمر بسيطًا ومجانيًا، وقد حصل على حوالي 9,000 نجمة على GitHub من خلال القيام بشيء واحد بشكل جيد. ثم، في 4 يناير 2023، تم أرشفة المستودع. لا توفر وثيقة README الكلمات: توقف المشروع، وتراكمت المشكلات، ويذكر القائمون على الصيانة الآن بوضوح أن "استخدامه لم يعد موصى به". يشيرون إليك إلى قائمة awesome-grpc ويتمنون لك حظًا سعيدًا.

إليك الإجابة المباشرة: Apidog هو أفضل بديل لـ BloomRPC لمعظم الفرق، لأنه لا يحل محل نافذة تحميل .proto فقط. إنه يدعم جميع أنواع مكالمات gRPC الأربعة (أحادية، تدفق الخادم، تدفق العميل، والتدفق ثنائي الاتجاه)، ويستورد ملفات .proto من مسار محلي، أو عنوان URL، أو انعكاس الخادم، ويضع عمل gRPC الخاص بك في نفس المشروع مع نقاط نهاية REST و WebSocket و GraphQL الخاصة بك، مع الوثائق والتعاون وإعدادات التصحيح المحفوظة. إذا كنت تحتاج فقط إلى مكالمة لمرة واحدة من طرفية، توجد أدوات أخف، وسنغطيها بصراحة أيضًا. تشرح هذه المقالة ما مات مع BloomRPC، وماذا تحل محله، وكيفية الترحيل بالضبط.

ماذا كان BloomRPC، ولماذا اختفى

تم إطلاق BloomRPC في عام 2018 كتطبيق سطح مكتب مبني على Electron بمهمة واحدة: إجراء مكالمات gRPC دون الحاجة إلى كتابة عميل. كنت تستورد ملفات .proto الخاصة بك، فيقوم بإدراج الخدمات والأساليب، ويولد هيكل JSON لكل رسالة طلب، ويسمح لك بتحرير البيانات الوصفية وإرسالها. بالنسبة للمكالمات أحادية الاتجاه والتدفق الأساسي كان الأمر جيدًا، و "الجيد والمجاني" جعله واجهة المستخدم الرسومية الافتراضية لـ gRPC لسنوات.

ينتهي إشعار الأرشيف تلك الحقبة بشكل نظيف. يعني المستودع المؤرشف عدم وجود إصلاحات للأخطاء، ولا تحديثات للتبعيات، ولا إصدارات جديدة. بالنسبة لتطبيق Electron، هذه ليست حالة محايدة: إصدارات Chromium و Node المدمجة تخرج من دعم الأمان، ولا يتم التعامل مع بناء جملة proto الأحدث وميزات gRPC، وتبقى الأخطاء المعروفة (كان لدى BloomRPC أخطاء طويلة الأمد تتعلق باستيراد proto وتدفقات بث معينة) كما هي بالضبط. كان القائمون على الصيانة صادقين بشأن ذلك، وهو أكثر مما تديره العديد من المشاريع الميتة. الرسالة هي: توقف عن تثبيت هذا.

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

الجواب: Apidog

Apidog هي منصة لتطوير واجهات برمجة التطبيقات (API) يستخدمها أكثر من 500,000 مطور، وتغطي التصميم والتصحيح والاختبار والمحاكاة والتوثيق. يدعم Apidog gRPC، ووفقًا للوثائق الرسمية، يغطي ما فعله BloomRPC والأجزاء التي لم يكملها BloomRPC أبدًا:

1. جميع أنواع المكالمات الأربعة. يتم دعم المكالمات أحادية الاتجاه، وتدفق الخادم، وتدفق العميل، والتدفق ثنائي الاتجاه. تعمل مكالمات التدفق مثل جلسة WebSocket: افتح المكالمة، ثم اكتب وأرسل الرسائل من علامة تبويب "الرسائل" بينما يعرض عرض المخطط الزمني الرسائل المرسلة والمستلمة بالترتيب. كان دعم التدفق في BloomRPC جزئيًا وبه أخطاء في النهاية؛ هنا هو ميزة موثقة.
2. ثلاث طرق لاستيراد تعريف واجهة برمجة التطبيقات الخاصة بك. قم بتحميل ملف .proto محلي، أو استورد من عنوان URL، أو استخدم انعكاس الخادم لسحب الخدمات مباشرة من خادم gRPC قيد التشغيل دون الحاجة إلى ملفات proto. إذا كانت ملفات proto الخاصة بك تعتمد على ملفات proto أخرى، يمكنك إضافة دليل التبعية مرة واحدة.
3. JSON للداخل، JSON للخارج. مثل BloomRPC، يقوم Apidog بعرض رسائل protobuf كـ JSON قابل للتحرير، لذلك لا تقوم بتشفير البيانات الثنائية يدويًا. إذا كنت بحاجة إلى فهم هذا التعيين، راجع protobuf إلى JSON.
4. TLS، البيانات الوصفية، والمصادقة. قم بالتبديل بين grpc:// أو grpcs:// لكل طلب، وقم بإرفاق البيانات الوصفية وتكوين المصادقة للإعدادات التي تحتوي عليها الخدمات الحقيقية بالفعل. لأنماط الرمز المميز و mTLS، يتناسب دليل مصادقة gRPC الخاص بنا جيدًا مع هذا.
5. إنه ليس طريقًا مسدودًا. مكالمات gRPC المحفوظة (عنوان URL للخادم، الرسائل، البيانات الوصفية) قابلة للمشاركة مع الزملاء، وتعيش في نفس مساحة العمل كنقاط نهاية REST الخاصة بك، وسيناريوهات الاختبار، والمستندات المنشورة. هذا هو الجزء الذي لم تقدمه أي نافذة gRPC مستقلة على الإطلاق.

كيف يبدو التغيير ميزة بميزة

إجراء المكالمات

الاستخدام اليومي سيشعر مألوفاً. قم باستيراد ملفات البروتو، اختر خدمة وطريقة، قم بتحرير نص JSON المُنشأ، اضبط عنوان الخادم، ثم أرسل. المكالمات الأحادية ترجع لوحة استجابة؛ تفتح مكالمات التدفق جلسة حيث تدفع الرسائل وتشاهد المخطط الزمني. تعود رموز الحالة كرموز حالة gRPC، والتي تُقرأ بشكل مختلف عن HTTP؛ احتفظ بمرجع رمز حالة gRPC في متناول اليد في الأسبوع الأول.

البث، على وجه التحديد

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

انعكاس الخادم

تطلب BloomRPC ملفات proto. يدعم Apidog أيضًا انعكاس الخادم، بحيث يمكنك توجيهه إلى خادم ممكّن للانعكاس وتصفح خدماته دون البحث عن مراجعة proto الصحيحة. للتجول بسرعة في خادم مؤقت يملكه شخص آخر، هذا يزيل الخطوة الأكثر إزعاجًا.

ما وراء العميل

إليك القفزة النوعية. في BloomRPC، تتبخر المكالمة التي تم تصحيحها عند إغلاق النافذة. في Apidog، توجد خدمات gRPC داخل مشروع: يعيد الزملاء استخدام إعداد تصحيح الأخطاء المحفوظ الخاص بك بدلاً من إعادة استيراد ملفات proto وإعادة كتابة البيانات الوصفية، وتحتوي مساحة العمل نفسها على أعمال REST و WebSocket الخاصة بك، واختبارات gRPC API المؤتمتة، والمحاكاة لنقاط نهاية HTTP الخاصة بك، والوثائق القابلة للنشر. معظم واجهات gRPC الخلفية تخدم REST أو GraphQL في مكان ما أيضًا؛ إذا كنت توازن بين حدود البروتوكولات هذه، فقد قمنا بمقارنتها في REST مقابل GraphQL مقابل gRPC وتعمقنا في المفاضلات في gRPC مقابل REST.

BloomRPC مقابل Apidog في لمحة

الترحيل من BloomRPC

ملاحظة الترحيل الصادقة: لا يوجد شيء للتصدير. لم يحتفظ BloomRPC بأي حالة محمولة ذات معنى، مما يجعل التخلي عنه أمرًا تافهًا:

1. اجمع ملفات .proto الخاصة بك. تعيش هذه الملفات في المستودع الخاص بك، وليس في BloomRPC. هذا هو "التصدير" بالكامل.
2. الاستيراد إلى Apidog. أنشئ مشروعًا، أضف ملفات proto (أو عنوان URL الخاص بها)، وأضف أدلة التبعيات إذا كانت ملفات proto الخاصة بك تستورد ملفات أخرى. تظهر الخدمات وطرق rpc كخدمات وطرق. أو تخطى الملفات تمامًا واستخدم انعكاس الخادم مقابل خادم قيد التشغيل.
3. اضبط عنوان الخادم و TLS. أدخل عنوان URL الهدف واختر grpc:// أو grpcs://.
4. أعد إنشاء البيانات الوصفية والمصادقة. أعد إضافة الرؤوس والرموز المميزة التي كنت قد ألصقتها في BloomRPC، هذه المرة يتم حفظها مع الطلب بحيث تكتبها مرة واحدة.
5. الحفظ والمشاركة. تصبح المكالمات المحفوظة إعداد التصحيح المشترك للفريق، وهو أول شيء ستلاحظ أنك لم تمتلكه من قبل.

يجب أن يكون مستخدم BloomRPC العامل قادرًا على إرسال المكالمات في Apidog في غضون عشر دقائق، لأن الخطوات من 1 إلى 3 هي نفس الطقوس التي تعرفها بالفعل.

بدائل BloomRPC الأخرى الجديرة بالمعرفة

Apidog هو الحل إذا كنت ترغب في دمج gRPC داخل منصة API كاملة. إذا كانت حاجتك أضيق، فكن منصفًا للأدوات الضيقة:

• grpcurl: أداة curl لـ gRPC. الأداة المناسبة لبرامج الشل، وفحوصات CI، والأوامر ذات السطر الواحد ضد الخوادم التي تدعم الانعكاس؛ ليست واجهة مستخدم رسومية ولا تدعي أنها كذلك. قمنا بمقارنتها بعمق في أفضل بديل لـ grpcurl.
• grpcui: شقيق grpcurl الذي يقدم واجهة مستخدم ويب مؤقتة لخادم واحد. جيد للتجربة السريعة لمدة خمس دقائق، بدون حالة محفوظة حسب التصميم.
• Kreya: عميل سطح مكتب مخصص لـ gRPC و REST مع سير عمل proto مصقول وطبقة مجانية؛ أقرب شيء لخليفة BloomRPC المباشر إذا كنت تريد بشكل خاص عميلًا مستقلاً. راجع ما هو Kreya و أفضل بديل لـ Kreya لمعرفة حدوده.
• Postman: أضاف دعم gRPC في عام 2022، لذا إذا كان فريقك يدفع ثمنه بالفعل، فهو يعمل؛ تنطبق تسعيرات Postman المعتادة ومفاضلات مساحة العمل، وهي مغطاة في أفضل بديل لـ Postman.
• evans: REPL طرفية لـ gRPC مع وضع تفاعلي. يحبه الأشخاص الذين يعيشون في tmux؛ غير مناسب لأي شخص أراد واجهة المستخدم الرسومية لـ BloomRPC.

النمط: واجهات سطر الأوامر (CLIs) للأتمتة، واجهات المستخدم الرسومية (GUIs) ذات الغرض الواحد لعمل gRPC المعزول، Apidog عندما يكون gRPC بروتوكولًا واحدًا من بين عدة بروتوكولات وتريد المكالمات والاختبارات والوثائق في مكان واحد.

الأسئلة المتداولة

هل BloomRPC لا يزال قيد الصيانة؟

لا. تم أرشفة المستودع في 4 يناير 2023، وتنص وثيقة README الخاصة به على أن استخدامه لم يعد موصى به. لا توجد تحديثات أو إصلاحات أمنية أو إصدارات قادمة. يجب أن يستبعد أي مقارنة حالية لعملاء gRPC BloomRPC كخيار للإعدادات الجديدة.

هل يمكنني استيراد إعداد BloomRPC الخاص بي إلى Apidog؟

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

هل يدعم Apidog تدفق gRPC؟

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

ماذا لو كنت أحتاج فقط إلى مكالمات gRPC سريعة عبر سطر الأوامر؟

استخدم grpcurl. إنه يتعامل مع المكالمات المبرمجة والمخصصة جيدًا، خاصة ضد الخوادم التي تدعم الانعكاس، وينتمي إلى CI بغض النظر عن واجهة المستخدم الرسومية التي تختارها. يغطي دليلنا لبديل grpcurl أين يتوقف عن كونه كافيًا.

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

في Apidog، نعم: تعيش gRPC و REST و WebSocket و SSE و GraphQL في مشروع واحد، لذلك تحصل الخدمة التي تعرض كلاً من واجهات gRPC و REST على منزل واحد. يوضح دليلنا لاختبار واجهات برمجة تطبيقات gRPC سير العمل من البداية إلى النهاية.

أوقف استخدام العميل المؤرشف

أخبرك BloomRPC بالمغادرة؛ السؤال الوحيد هو إلى أين. وجه Apidog إلى ملفات .proto الخاصة بك أو خادم يدعم الانعكاس، وقم بإجراء أول مكالماتك الأحادية والتدفقية، واحتفظ بها محفوظة بجانب بقية أعمال واجهة برمجة التطبيقات الخاصة بك. قم بتنزيل Apidog مجانًا؛ فريق مكون من 4 أفراد لا يدفع شيئًا، وملفات proto الخاصة بك هي ملف الترحيل الوحيد الذي تحتاجه.