أفضل أدوات CLI خفيفة الوزن للتطوير

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

أدوات سطر الأوامر (CLI) خفيفة الوزن تعكس ذلك. يتم شحنها كملف ثنائي واحد أو حزمة قابلة للتنفيذ بواسطة npx، وتبدأ في أقل من ثانية، وتؤدي مهمة واحدة دون معالج إعداد. يمكنك ربطها بسكربتات shell ومهام التكامل المستمر (CI)، وتبقى بعيدًا عن طريقك. بالنسبة لعمل الواجهة البرمجية (API) والواجهة الخلفية، تغطي مجموعة صغيرة من هذه الأدوات معظم الدورة: إرسال الطلبات، تحليل الاستجابات، كشف منفذ محلي، وتشغيل مجموعة الاختبارات الخاصة بك.

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

ما الذي يجعل أداة سطر الأوامر "خفيفة الوزن" للتطوير

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

• حجم وشكل التثبيت. ملف ثنائي ثابت واحد أو حزمة npx صغيرة تتفوق على أي شيء يسحب بيئة تشغيل وملف قفل وراءه.
• سرعة البدء. يجب أن تكون الأداة قيد التشغيل قبل أن تعود إلى محرر النصوص الخاص بك. تبدأ الملفات الثنائية لـ Rust وGo في غضون أجزاء من الثانية، وهو أمر مهم عندما تستدعيها في حلقة.
• الإعداد للنتيجة الأولى. يعتبر الإعداد الصفري لنتيجة افتراضية مفيدة هو المعيار. إذا كانت تحتاج إلى ملف مشروع، وحساب، ولوحة تحكم أولاً، فهي ليست خفيفة الوزن.
• قابلية التركيب. تقرأ المدخلات القياسية (stdin)، تكتب المخرجات القياسية (stdout)، تعين رمز خروج حقيقي، وتُمرر إلى الأداة التالية. هذا ما يجعل الأداة الصغيرة ذات قيمة أكبر من حجمها.

الأدوات أدناه تتدرج تقريبًا من الأصغر والأكثر أحادية الغرض إلى الأكثر اكتمالاً. curl موجود بالفعل على جهازك؛ والبقية تتطلب تثبيتًا سريعًا.

curl

curl هو المعيار الذي تقاس عليه جميع أدوات HTTP الأخرى. إنه موجود على كل جهاز تقريبًا بالفعل، ويتحدث كل بروتوكول ستتعامل معه، ويفعل بالضبط ما تطلبه منه. لإجراء فحص سريع لنقطة نهاية ما، لا يوجد أسرع منه.

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue"}'

تقوم العلامة -s بكتم عداد التقدم بحيث تمر الاستجابة بشكل نظيف. أضف -i لرؤية الرؤوس (headers)، و -w '%{http_code}' لطباعة رمز الحالة فقط، و --fail لجعل curl يعيد قيمة خروج غير صفرية عند 4xx أو 5xx، وهذا ما تريده داخل فحص CI.

الأفضل لـ: السكربتات، فحوصات سلامة CI، وأي طلب تريد نسخه ولصقه ومشاركته. يعمل أمر curl على جهاز أي زميل.

حدود صريحة: بناء جملة العلامات كثيف ومعالجة جسم JSON يدوية. للطلبات التفاعلية السريعة، الأداتان التاليتان أكثر سهولة.

HTTPie

HTTPie (http) هو curl ولكن مع إزالة الحواف الحادة، وقد بُني للبشر الذين يكتبون الطلبات يدويًا. JSON هو الافتراضي، المخرجات ملونة ومنسقة، وتقوم ببناء طلب من عناصر key=value بسيطة بدلاً من تذكر العلامات.

http POST httpbin.org/post name=apidog role=api-tool active:=true

يرسل ذلك جسم JSON من {"name": "apidog", "role": "api-tool", "active": true}. تقوم = بتعيين سلسلة نصية، و := بتعيين قيمة JSON خام، و header:value بتعيين رأس (header). لا يوجد اقتباس لكتلة JSON، ولا حسابات -H و -d. تأتي الاستجابة مطبوعة بشكل جميل.

الأفضل لـ: استكشاف API التفاعلي حيث تكون قابلية القراءة هي الأهم.

حدود صريحة: إنها حزمة بايثون، لذا تبدأ أبطأ من الملف الثنائي الأصلي وتحتاج إلى بايثون على الجهاز. إذا كانت سرعة البدء مهمة، استخدم xh.

xh

xh هو بناء جملة HTTPie في ملف ثنائي واحد من Rust. إنه يعيد تطبيق أسلوب عنصر الطلب الخاص بـ HTTPie، لذا تعمل name=value و := بنفس الطريقة، لكنه يشحن كملف واحد مرتبط بشكل ثابت بدون وقت تشغيل ويبدأ أسرع بنسبة 30٪ تقريبًا. كما يدعم HTTP/2 و HTTP/3.

xh POST httpbin.org/post name=apidog age:=24

نفس سهولة الاستخدام مثل HTTPie، وبدء فوري تقريبًا. لأنه ملف ثنائي واحد بدون تبعيات، فإنه يدخل في صورة CI خفيفة أو حاوية دون سحب بايثون معه. مشروع xh على GitHub يشحن ملفات ثنائية مسبقة الإنشاء لأنظمة Linux و macOS و Windows.

الأفضل لـ: المطورين الذين يحبون إحساس HTTPie ولكن يريدون سرعة أصلية وتثبيتًا بدون تبعيات للسكربتات والحاويات.

حدود صريحة: يغطي السطح المشترك لـ HTTPie، وليس كل مكون إضافي أخير. بالنسبة لجميع أعمال الطلبات تقريبًا، لا تظهر هذه الفجوة أبدًا.

jq

jq تجعل كل أداة HTTP أخرى أكثر فائدة. إنه ملف ثنائي واحد يقوم بتصفية وإعادة تشكيل JSON في سطر الأوامر، بحيث يمكنك سحب حقل واحد من استجابة API بدلاً من فحص الكتلة بأكملها.

curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'

يطبع ذلك عدد النجوم فقط. يحتوي jq على لغة استعلام كاملة: .items[] | .name تقوم بالمرور عبر مصفوفة، select(.active) تقوم بالتصفية، و -r يعطي إخراجًا خامًا بدون علامات اقتباس بحيث يمكنك تمريره إلى متغير shell. إنه الرابط بين استدعاء API وبقية سكربتك.

الأفضل لـ: استخراج وتحويل الحقول من استجابات JSON في السكربتات و CI.

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

gh (GitHub CLI)

يجلب gh واجهة برمجة تطبيقات GitHub إلى طرفيتك دون أن تكتب استدعاء curl واحدًا ضدها. يتعامل مع المصادقة مرة واحدة عبر gh auth login، ثم يغلف طلبات السحب والمشكلات والإصدارات والمستودعات في أوامر بسيطة. بالنسبة لفرق الواجهة الخلفية التي تعتمد على GitHub في سير عمل النشر والمراجعة، فإنه يزيل علامة تبويب المتصفح من الحلقة.

gh pr create --title "Add rate limiting" --body "Closes #42" --base main

يفتح هذا طلب سحب من فرعك الحالي. يراقب gh pr checks التكامل المستمر، ويتابع gh run watch سير العمل مباشرة، ويوفر gh api عميلًا مصادقًا عليه ومقسمًا على صفحات لأي نقطة نهاية لا تغطيها الأوامر المغلفة.

الأفضل لـ: سَكْرَبَة GitHub نفسها: فتح طلبات السحب من CI، وإصدار الإصدارات، والاستعلام عن API دون إدارة الرموز يدويًا.

حدود صريحة: إنه مخصص لـ GitHub فقط، لذا فإن ورشة عمل GitLab أو Bitbucket لن تستفيد منه شيئًا.

ngrok

يكشف ngrok منفذًا محليًا إلى عنوان URL عام عبر نفق آمن. هل تقوم بإنشاء معالج ويب هوك (webhook)، أو تحتاج إلى شخص ما للوصول إلى خادم التطوير الخاص بك من خارج شبكتك؟ يحول `localhost` إلى رابط قابل للمشاركة بأمر واحد. الوكيل هو ملف ثنائي بدون تبعيات يعمل في أي مكان.

ngrok http 8080

يقوم هذا بتحويل URL عام `https://` إلى المنفذ المحلي 8080 ويطبعه في الطرفية. كما يقوم بتشغيل مفتش حركة المرور على `http://127.0.0.1:4040` حيث يمكنك إعادة تشغيل كل طلب مرّ، وهو ما يوفر الوقت حقًا عند تصحيح أخطاء مدفوعات أو Git webhook لا تتحكم فيه.

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

حدود صريحة: إنها خدمة تجارية مع طبقة مجانية؛ الخطة المجانية تدور عنوان URL الخاص بك في كل جلسة وتحد من معدل استخدامه. لـ HTTPS محلي ثابت باسم ثابت، استخدم mkcert بدلاً من ذلك.

mkcert

يُنشئ mkcert شهادات HTTPS موثوقة محليًا بدون أي إعدادات. مكتوب بلغة Go بواسطة Filippo Valsorda، وهو ملف ثنائي واحد يُنشئ مرجع مصدق محليًا، ويثبته في مخازن الثقة في نظامك، ويصدر شهادات يقبلها متصفحك دون تحذير. هذه هي الطريقة التي تشغل بها `https://localhost` محليًا بدون القفل الأحمر المخيف.

mkcert -install
mkcert localhost 127.0.0.1 myapp.local

يقوم السطر الأول بإعداد المرجع المصدق المحلي مرة واحدة. يُصدر السطر الثاني شهادة ومفتاحًا للأسماء التي تُدرجها، جاهزين لتسليمها لخادم التطوير أو الوكيل العكسي. لا توجد تعويذات OpenSSL، ولا شهادة موقعة ذاتيًا تنقر عليها لتتجاوزها مع كل إعادة تحميل. يصبح اختبار إعادة توجيهات OAuth، أو ملفات تعريف الارتباط الآمنة، أو أي شيء يتصرف بشكل مختلف عبر HTTPS أسهل بكثير.

الأفضل لـ: الحصول على HTTPS حقيقي وموثوق به في بيئة تطوير محلية ليتطابق مع بيئة الإنتاج.

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

watchexec

يعيد watchexec تشغيل أمر عندما تتغير الملفات. إنه ملف ثنائي واحد من Rust يراقب دليلًا ويعيد تشغيل خادمك أو يعيد تشغيل اختباراتك لحظة الحفظ. إنه يحترم `.gitignore` افتراضيًا، لذا لن يتم تشغيله على مكونات البناء.

watchexec -e py -r 'pytest tests/'

تقوم -e py بتصفية ملفات بايثون، و -r تعيد تشغيل عملية طويلة الأمد بدلاً من تكديس عمليات جديدة. وجهه إلى أي أمر: watchexec -r 'go run .' لخادم Go، و watchexec 'npm test' لمجموعة JS. إنه محايد للغة، لذا تغطي أداة واحدة كل مشروع بدلاً من مراقب خاص بكل مكدس.

الأفضل لـ: حلقات التعديل والتشغيل الضيقة على خادم محلي أو مجموعة اختبار، بدون وضع مراقبة خاص بإطار العمل.

حدود صريحة: إنه يراقب ويعيد التشغيل؛ لا يقوم بإعادة تحميل الوحدات النمطية الساخنة أو يحافظ على الحالة داخل العملية.

Docker CLI

يُعد Docker CLI الأداة الأثقل هنا، وهو يستحق مكانه. عندما تحتاج إلى Postgres حقيقي، أو Redis، أو تبعية كاملة للتطوير المحلي، يمنحك أمر docker run واحد نسخة يمكن التخلص منها عند الانتهاء. لا يوجد تثبيت على مستوى النظام، ولا خدمات متبقية.

docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16

تقوم --rm بحذف الحاوية عند الخروج، و -e يضبط كلمة المرور، و -p يربط المنفذ بمضيفك. يتصل تطبيقك بـ localhost:5432 وتحصل على قاعدة بيانات نظيفة مع كل تشغيل. استبدل postgres:16 بـ redis:7 أو أي صورة وسينطبق النمط.

الأفضل لـ: تشغيل الخدمات الخلفية للتطوير المحلي واختبارات التكامل، بشكل قابل للتكرار، دون تلويث جهازك.

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

apidog-cli

بمجرد أن تقوم بعمل API في سطر الأوامر، فإن القطعة المفقودة هي مشروع API الفعلي الخاص بك: نقاط النهاية، المخططات، البيئات، وسيناريوهات الاختبار. تقدم Apidog أداة apidog-cli، وهي أداة سطر أوامر خفيفة الوزن تربط الطرفية بهذا المشروع. يتم تثبيتها كحزمة npm واحدة وتمنحك مسارًا برمجيًا لتصميم واستيراد واختبار الموارد وتقليدها دون فتح تطبيق سطح المكتب.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run -t <scenario_id> -e <env_id> -r cli

يقوم apidog run بتنفيذ سيناريو اختبار محفوظ مقابل بيئة ما ويطبع نتيجة خطوة بخطوة في الطرفية. يخرج 0 عندما تنجح جميع التأكيدات ويكون غير صفري عند الفشل، لذلك يندرج مباشرة في بوابة CI. بالإضافة إلى الاختبارات، تغطي CLI مجموعات أوامر حقيقية: endpoint و schema للتصميم، import و export لنقل المواصفات (OpenAPI، Swagger، Postman) داخل وخارج، mock لتوقعات التقليد، و environment و variables للإعداد. الإخراج هو JSON منظم مع agentHints.nextSteps، وهذا هو السبب في أنه يناسب أيضًا مساعدي الترميز بالذكاء الاصطناعي الذين يقومون بتطوير API. للحصول على المرجع الكامل للأوامر، راجع دليل Apidog CLI الكامل؛ يوضح دليل تثبيت Apidog CLI التشغيل الأول.

الأفضل لـ: تشغيل سيناريوهات الاختبار الخاصة بك في CI وإدارة موارد المشروع من السكربتات، خاصة في سير عمل تطوير API المعتمد على المواصفات حيث يقود العقد كل شيء.

ملاحظة صريحة: Apidog ليس مفتوح المصدر؛ إنه منتج تجاري مع طبقة مجانية. لكن تلك الطبقة المجانية بالإضافة إلى CLI تمنحك بديلاً متكاملًا لتجميع عميل طلب، وخادم وهمي، ومُشغل اختبار معًا بنفسك، وكل ذلك مدعوم بمشروع واحد. الجزء الخفيف الوزن هو الملف الثنائي apidog-cli؛ منصة Apidog الكاملة هي واجهة رسومية فوق نفس المشروع.

كيف تختار

معظم هذه الأدوات مكملة لبعضها البعض، وليست متنافسة. من المرجح أن تقوم بتشغيل العديد منها: عميل HTTP، و jq، ونفق، ومراقب، ومشغل اختبار.

اختر حسب المهمة. إرسال الطلبات: xh أو HTTPie للعمل التفاعلي، curl للسكربتات. قراءة الاستجابات: دائمًا jq. كشف منفذ: ngrok. HTTPS محلي: mkcert. إعادة التشغيل عند الحفظ: watchexec. خدمات الدعم: Docker. تشغيل اختبارات API وإدارة المشروع: apidog-cli.

خلاصة

المجموعة الجيدة من الأدوات الخفيفة الوزن هي مجموعة صغيرة من الأدوات السريعة، كل منها يقوم بمهمة واحدة وينقل الإخراج إلى الأداة التالية. ترسل curl و xh الطلبات، ويقرأها jq، ويتعامل ngrok و mkcert مع الوصول المحلي، ويغلق watchexec حلقة التعديل والتشغيل، ويوفر Docker بنية تحتية قابلة للتخلص منها. لا تطلب أي منها الكثير قبل أن تصبح مفيدة.

أداة apidog-cli هي الجزء الذي يربط الحلقة بمشروع API الفعلي الخاص بك، بحيث تكون نقاط النهاية والاختبارات التي تشغلها من الطرفية هي نفسها التي يقوم فريقك بتصميمها وشحنها. قم بتنزيل Apidog لإعداد مشروع، ثم قم بإدارته من سطر الأوامر باستخدام CLI في مسار CI الخاص بك. نفس فكرة السرعة والبصمة، مطبقة على دورة حياة API بأكملها بدلاً من طلب واحد في كل مرة.