كان تثبيت Node بطيئًا لسنوات. تشغل npm install، تذهب إلى آلة القهوة، تعود، ولا تزال CI تقوم بحل @types/node. Aube يغير هذه المعادلة. ينهي تثبيتًا دافئًا لـ CI لمشروع حقيقي يحتوي على 1,400 حزمة في 139 مللي ثانية، وهو أسرع بحوالي 7.3 مرة من pnpm و 3 مرات أسرع من Bun على نفس الجهاز. الجزء المثير للاهتمام حقًا: إنه يقرأ ويكتب ملف القفل الحالي الخاص بك، لذا يمكنك تجربته يوم الاثنين دون أن تطلب من أي شخص الترحيل.
يشمل هذا الدليل ما هو Aube، وكيف يحقق هذه الأرقام، وكيفية تثبيته، وكيف يقارن بـ pnpm و npm و yarn و Bun، ومكانته إذا كنت تبني واجهات برمجة التطبيقات باستخدام أدوات مثل Apidog كل يوم.
ما هو Aube؟
Aube هو مدير حزم Node.js سريع بناه en.dev وأصدره تحت ترخيص MIT. الاسم يعني "فجر" بالفرنسية ويُنطق "أوب". المشروع في مرحلة البيتا (v1.0.0-beta.10 وقت الكتابة) ويستهدف التوافق مع pnpm v11 كهدف رئيسي.

الفكرة بسيطة ومباشرة. يستخدم Aube نفس نموذج التخزين على القرص مثل pnpm، وهو متجر عالمي قابل للعنونة بالمحتوى بالإضافة إلى تخطيط symlink معزول، ولكن مسار التثبيت مكتوب بلغة متعددة الخيوط الأصلية بدلاً من JavaScript. نفس التخطيط، محرك أسرع. هذا الاختيار التصميمي الوحيد هو ما يسمح له بالتفوق على Bun في عدة سيناريوهات قياسية مع الاستمرار في كتابة pnpm-lock.yaml في مكانه.
إذا كنت قد قمت بالترحيل بين مديري الحزم مرة واحدة، فأنت تعلم أن التكلفة الحقيقية ليست الأداة؛ إنها التكلفة الاجتماعية لجعل كل فرد في فريقك يغير طريقة تشغيل install. يتجاوز Aube ذلك بقراءة pnpm-lock.yaml و package-lock.json و npm-shrinkwrap.json و yarn.lock و bun.lock مباشرة. يمكنك تشغيله محليًا بينما لا يزال CI يستخدم pnpm، ولا يتغير شيء لزملائك في الفريق.
معايير Aube: ما مدى سرعة "الأسرع"؟
تعتمد أداة القياس على مشروع حقيقي يضم حوالي 1,400 حزمة وتم توقيتها باستخدام hyperfine. يفترض كل سيناريو وجود ملف قفل ملتزم. المحور المتغير هو دفء ذاكرة التخزين المؤقت: تعمل "دافئة" على مسح node_modules ولكنها تحتفظ بالمتجر العالمي وذاكرة التخزين المؤقت للحزم، بينما تعمل "باردة" على مسح كل شيء.
الأرقام من المعايير الرسمية (aube 1.0.0-beta.3, bun 1.3.12, pnpm 10.33.0, npm 11.12.1, yarn 1.22.22, node 24.15.0):
| السيناريو | aube | bun | pnpm | yarn | npm |
|---|---|---|---|---|---|
| تثبيت CI (ذاكرة تخزين مؤقت دافئة، لا يوجد node_modules) | 139 مللي ثانية | 416 مللي ثانية | 1.01 ثانية | 2.43 ثانية | 2.78 ثانية |
| تثبيت CI (ذاكرة تخزين مؤقت باردة، لا يوجد node_modules) | 1.12 ثانية | 935 مللي ثانية | 1.57 ثانية | 6.60 ثانية | 4.21 ثانية |
install && run test (مثبت بالفعل) |
21 مللي ثانية | 42 مللي ثانية | 453 مللي ثانية | 351 مللي ثانية | 615 مللي ثانية |
إضافة تبعية (add is-odd) |
209 مللي ثانية | 414 مللي ثانية | 1.33 ثانية | 2.55 ثانية | 2.89 ثانية |
تبرز عدة أمور. يعتبر رقم تثبيت CI الدافئ هو العنوان الرئيسي لأنه يعكس الحالة الأكثر شيوعًا في المسارات الحقيقية، حيث يستعيد المشغل ذاكرة تخزين مؤقت ويظل متجرك العالمي يحتوي على كل حزمة مضغوطة. في هذا السيناريو، Aube أسرع بحوالي 7.3 مرة من pnpm و 3 مرات أسرع من Bun.
يقيس سيناريو install && run test حلقة المطور اليومية. يجب على كل أداة أن تقرر "هل أحتاج إلى التثبيت أولاً، ثم تشغيل السكريبت؟" يمكن لـ Aube تخطي عمل التثبيت بالكامل عندما يكون ملف حالة التثبيت الخاص به جديدًا، لذلك تعود حلقة install && test بأكملها في 21 مللي ثانية. لا تزال الأدوات الأخرى تعيد التحقق من ملف القفل قبل إرسال السكريبت، وهذا هو المكان الذي تأتي منه التكلفة الإضافية من 400 إلى 600 مللي ثانية.
في حالة ذاكرة التخزين المؤقت الباردة، يتفوق Bun على Aube (935 مللي ثانية مقابل 1.12 ثانية) لأن مسار جلب حزم Bun مُحسّن للغاية، وتسيطر عمليات الإدخال والإخراج على التثبيتات الباردة. أما السيناريو الدافئ فهو الذي يُشغل آلاف المرات يوميًا في فريق تطوير نموذجي؛ ويُشغل البارد مرة واحدة شهريًا عندما تقوم بمسح المشغل.
عبر المجموعة الكاملة من أدوات الاختبار، تشير الوثائق إلى ذروات تصل إلى 22 ضعفًا أسرع من pnpm وحتى 3 أضعاف أسرع من Bun اعتمادًا على السيناريو. يمكنك تكرار كل هذا محليًا باستخدام mise run bench من مستودع Aube.
لماذا Aube أسرع من pnpm و Bun
ثلاثة خيارات تصميمية تقوم بالعمل الشاق.
مسار تثبيت أصلي ومتعدد الخيوط. يقوم كل من npm و pnpm و yarn بتشغيل محرك التثبيت في Node.js. وهذا يعني أن كل تجزئة، وكل استخراج لحزمة مضغوطة، وكل استدعاء للوصلة الرمزية يدفع ضريبة إرسال JavaScript. ينقل Aube المسار الساخن من V8 إلى وقت تشغيل مجمّع أصليًا ومتعدد الخيوط أصليًا. يقوم Bun بشيء مشابه ولكنه يشحن وقت تشغيل JavaScript كاملاً بجانب مدير الحزم الخاص به؛ Aube مصمم خصيصًا لمسار التثبيت، وهذا جزء من سبب تفوقه على Bun في عمليات التثبيت الدافئة.
المخزن الافتراضي العالمي هو الافتراضي. أضاف pnpm v11 enableGlobalVirtualStore، لكنه ليس الافتراضي لتثبيتات المشاريع. يعتمد Aube افتراضيًا على مخزن افتراضي عالمي، لذلك ترتبط المشاريع المتكررة ذات التبعيات المتداخلة في الغالب بأشجار الحزم الموجودة بالفعل على القرص. إذا كان لديك ثلاث خدمات تستخدم جميعها React و Vite و TypeScript و Playwright، فإن الملفات الثقيلة تعيش في مكان واحد وكل مشروع يرتبط بها رمزيًا. تقدر الوثائق تقليلًا بنسبة 90٪ في مساحة القرص مقارنة بـ npm في إعدادات المستودعات المتعددة النموذجية.
اختصار التثبيت بملف حالة جديد. يتحقق aube run test أولاً من ملف حالة تثبيت مدمج. إذا تطابق تجزئة package.json وملف القفل مع ملف الحالة، فإن مرحلة التثبيت تكون استدعاء `stat` واحدًا ويتم إرسال الاختبار على الفور. هذا ما يقلل رقم install && test إلى 21 مللي ثانية.
لا يوجد سحر في هذا. إنه ما تحصل عليه عندما تأخذ تخطيط pnpm، وتزيل تمهيد JavaScript، وتصمم واجهة سطر الأوامر حول افتراض أن 99 بالمائة من عمليات التثبيت "لم يتغير شيء بالفعل".
كيفية تثبيت Aube
المسار الموصى به هو mise، مدير الأدوات متعدد اللغات:
mise use -g aube
تحقق من أنه وصل إلى PATH الخاص بك:
aube --version
إذا كنت تفضل npm:
npm install -g @endevco/aube
على نظام macOS أو Linux باستخدام Homebrew، يتوفر في Endev tap:
brew install endevco/tap/aube
داخل المشروع، يمكنك تثبيت إصدار Aube محليًا:
mise use aube
هذا يكتب aube كأداة في ملف mise.toml الخاص بك، مما يعني أن كل شل يدخل مجلد المشروع يحصل على نفس الإصدار. لا مزيد من "يعمل على جهازي لأنني قمت بتثبيت pnpm 10 العام الماضي". تغطي وثائق التثبيت أيضًا خيارات tarball والخيارات لكل نظام تشغيل.
الأوامر اليومية التي ستستخدمها بالفعل
واجهة الأوامر تحاكي pnpm عن كثب، لذا تنتقل الذاكرة العضلية:
aube install # تثبيت التبعيات
aube add react # إضافة تبعية
aube add -D vitest # إضافة تبعية تطوير
aube remove react # إزالة تبعية
aube update # التحديث ضمن نطاقات package.json
aube run build # تشغيل سكريبت package.json
aube test # تشغيل سكريبت الاختبار، مع التثبيت أولاً إذا كان قديمًا
aube exec vitest # تشغيل ثنائي محلي
aube dlx cowsay hi # تشغيل حزمة في بيئة مؤقتة
aube ci # تثبيت نظيف ومجمد لـ CI
يمكنك اختصار معظم هذه الأوامر. إذا كان السكريبت موجودًا في package.json، فإن aube dev هو نفسه aube run dev. هناك أيضًا اثنان من شيمز multicall (وظائف مساعدة متعددة الاستدعاءات) يتم شحنها في نفس الملف الثنائي:
aubr build # aube run build
aubx cowsay hi # aube dlx cowsay hi
استخدم aube ci في مسارات العمل. يقوم بإزالة node_modules، ويؤكد أن ملف القفل جديد لـ package.json الحالي، ثم يقوم بالتثبيت. إذا انحرف ملف القفل، فإنه يفشل بصوت عالٍ، وهو ما تريده في CI.
توافق ملفات القفل
هذه هي الميزة التي تجعل Aube خيارًا منخفض المخاطر للتبني. ليس عليك الالتزام بتحويل الفريق بأكمله.
| ملف القفل | يقرأ | يكتب في مكانه |
|---|---|---|
aube-lock.yaml |
نعم | نعم |
pnpm-lock.yaml v9 |
نعم | نعم |
package-lock.json v2/v3 |
نعم | نعم |
npm-shrinkwrap.json |
نعم | نعم |
yarn.lock (v1 كلاسيكي + v2+ berry) |
نعم | نعم |
bun.lock |
نعم | نعم |
النمط العملي يبدو كالتالي. يستخدم فريقك pnpm. لا يزال CI يشغل pnpm install --frozen-lockfile. تشغل أنت aube install محليًا على جهازك. يقرأ Aube ملف pnpm-lock.yaml، وينتج نفس تخطيط node_modules، ويكتب أي تحديثات للحل مرة أخرى في نفس ملف pnpm-lock.yaml. يسحب زميلك في الفريق فرعك، ويشغل pnpm install، ولا يوجد أي اختلاف. بمرور الوقت، إذا أثبت Aube كفاءته، تقوم بترحيل CI. وإذا لم يفعل، يمكنك إزالته ولن يعرف أحد في المراحل اللاحقة.
ملاحظتان: ملفات قفل pnpm v5 أو v6 القديمة تحتاج إلى ترقية باستخدام pnpm أولاً. وتحتاج مشاريع yarn PnP (نمط .pnp.cjs) إلى العودة إلى رابط node_modules لأن Aube يكتب node_modules، وليس PnP artifacts.
الإعدادات الافتراضية الآمنة أهم مما تتصور
إذا كنت قريبًا من أي قاعدة بيانات JavaScript في الأشهر الـ 18 الماضية، فقد رأيت حوادث سلسلة التوريد تتراكم. يغطي دليل أمان سلسلة توريد npm النمط؛ وكانت اختراق Axios npm واحدة من أوضح الحالات الواقعية لكيفية تمكن تبعية شائعة واحدة من شحن RAT (أداة وصول عن بعد) متعددة المنصات إلى آلاف أجهزة المطورين.
يتخذ Aube ثلاثة افتراضات موجهة تعتبر عمليات التثبيت كحدود أمان، وليست مجرد راحة:
- الحد الأدنى لعمر الإصدار. تنتظر الإصدارات الجديدة عمرًا أدنى قابل للتكوين قبل أن يقوم Aube بتثبيتها. الحزمة المخترقة حديثًا التي يتم سحبها في غضون ساعتين لا تلامس
node_modulesالخاصة بك أبدًا. - حظر التبعيات الغريبة. يمنع Aube التبعيات الانتقالية التي تبدو أشكالها مشبوهة (عناوين URL غير عادية، إدخالات تشبه التصحيحات، مراجع Git في أماكن تحمل عادةً semver). إذا كنت تريد واحدة بشكل صريح، فإنك توافق عليها.
- الموافقة على سكريبتات دورة الحياة. يتم تخطي سكريبتات
postinstallللتبعية بشكل افتراضي. تشغلaube approve-buildsللسماح بحزم معينة (esbuild، node-sass، أي شيء تحتاجه فعليًا للإنشاء محليًا). تظهر الحزم التي تم تخطي سكريبتاتها فيaube ignored-builds.
هذه السلوكيات الثلاثة لا تجعلك محصنًا، لكنها تحول "لم أكن أعلم أن هذه الحزمة قامت بتشغيل كود" إلى "اخترت السماح لهذه الحزمة بتشغيل كود". هذا هو الموقف الأمني الذي تريده قبل وقوع حادث الإنتاج التالي.
تخطيط وحدات Node
يستخدم Aube تخطيط node_modules معزول. يحتوي node_modules/ على المستوى الأعلى على التبعيات التي أعلنتها package.json الخاصة بك. تعيش التبعيات الانتقالية خلف node_modules/.aube/. يتم تخزين ملفات الحزمة نفسها مرة واحدة بالضبط في $XDG_DATA_HOME/aube/store/، والذي يُعيّن افتراضيًا إلى ~/.local/share/aube/store/.
ثلاثة نتائج:
- تشارك عدة مشاريع ذات تبعيات متداخلة ملفات الحزمة على القرص. لا مزيد من "لدي 12 نسخة من lodash عبر مستودعاتي المتعددة ومشاريعي الجانبية."
- تصبح التبعيات الوهمية أصعب. إذا لم تكن الحزمة موجودة في
package.jsonالخاصة بك، فلا يمكنكrequireها من المستوى الأعلى، لأنها ليست فيnode_modules/. هذا هو نفس الضمان الذي يوفره pnpm لك. - تُعيد عمليات التثبيت المتكررة استخدام الملفات الموجودة بالفعل على القرص. العمل الوحيد المتبقي هو الربط الصلب من المتجر إلى
node_modules/.aube/الجديد.
إذا كنت تعيش سابقًا على تخطيط node_modules مسطح (npm الكلاسيكي أو yarn v1)، فتوقع العثور على حزمة أو اثنتين معطلتين كانتا تعتمدان على واردات وهمية. الحل دائمًا هو "أضفه إلى package.json الخاص بك".
مساحات العمل والمستودعات المتعددة
يدعم Aube مساحات العمل وبروتوكول workspace::
aube install -r
aube run test -r
aube add zod --filter @acme/api
إذا كان مستودعك يحتوي بالفعل على pnpm-workspace.yaml، فإن Aube يقرأه ويكتبه. تستخدم مساحات العمل الجديدة التي تعتمد على Aube أولاً aube-workspace.yaml. تتطابق علامتا -r (المتكررة) و --filter مع نفس الدلالات التي تتوقعها من pnpm، لذا تستمر إعدادات turborepo و nx في العمل دون تغييرات.
بالنسبة لمستودعات API المتعددة، يعتبر رقم CI ذو ذاكرة التخزين المؤقت الدافئة هو الأهم. إذا كانت عملية البناء الخاصة بك تقوم بـ install, build, test, publish contract في كل عملية دمج، فإن تقليل وقت التثبيت من ثانية واحدة في pnpm إلى 139 مللي ثانية في Aube عبر عشر حزم يتراكم إلى دقائق حقيقية يوميًا.
مكانة Aube في سير عمل تطوير واجهة برمجة التطبيقات (API)
إذا كنت تقوم ببناء واختبار واجهات برمجة التطبيقات، فإن خطوات التثبيت تقع في المسار الحرج لكل عملية إعادة هيكلة. تقوم بتعديل مخطط طلب، وإعادة إنشاء عميل TypeScript، وإعادة التثبيت، وتشغيل اختبارات العقد مقابل خادم وهمي، وتكرار ذلك. التثبيت السريع ليس مقياسًا سطحيًا؛ إنه الفاصل الزمني بين "لقد غيرت هذا" و "أنا أعرف ما إذا كان قد تعطل".

حلقة عملية تعمل بشكل جيد:
- صمم وقم بعمل نموذج لواجهة برمجة التطبيقات في Apidog. تصميم المخطط أولاً يتفوق على تصميم الكود أولاً لأي شيء يتحدث إلى فريق آخر.
- قم بإنشاء عميل مكتوب (أو قم بتشغيل اختبارات العقود مقابل نموذج Apidog) داخل مشروع Node الخاص بك.
- استخدم Aube محليًا للحفاظ على التثبيتات في نطاق المللي ثانية بينما تقوم بالتكرار على العميل.
- ربط نفس مجموعة الاختبار بـ CI باستخدام
aube ci.
التحول في الأدوات بعيدًا عن Postman خلال العام الماضي هو جزء من نمط أكبر: المطورون يريدون أدوات سريعة، تركز على العمل المحلي أولاً، وآمنة افتراضيًا. Aube هو نفس القصة المطبقة على خطوة التثبيت. إذا كنت تستخدم بالفعل Apidog داخل VS Code، فإن إضافة Aube بجانبه يكلفك سطر واحد من mise use ويوفر ثوانٍ في كل إعادة تحميل سريعة.
الترحيل من كل مدير حزم
من npm. قم بتشغيل aube install في المشروع. يقرأ Aube ملف package-lock.json ويعيد كتابته. تحصل على node_modules معزولة بدلاً من المسطحة، لذا راقب الواردات الوهمية. إذا تعطل أحدهم، أضف الحزمة المفقودة إلى package.json وانتقل. سير العمل الكامل في دليل مستخدمي npm.
من pnpm. هذا هو الترحيل الأقل احتكاكًا لأن تخطيط التخزين على القرص هو نفسه. يقرأ Aube ملف pnpm-lock.yaml v9 مباشرة. يعمل بروتوكول workspace:. تعمل الفلاتر. تسرد صفحة pnpm-users عدد قليل من العلامات التي تتصرف بشكل مختلف.
من yarn. يقرأ Aube كلاً من ملفات قفل v1 الكلاسيكية و v2+ berry. يحتاج مستخدمو Yarn PnP إلى العودة إلى وضع nodeLinker: node-modules قبل تجربة Aube، لأن Aube يكتب node_modules وليس .pnp.cjs.
من Bun. يقرأ Aube ملف bun.lock. الفرق الرئيسي هو أن مدير حزم Bun مرتبط ارتباطًا وثيقًا بوقت تشغيل Bun’s JS؛ Aube هو أداة تثبيت مستقلة تعمل مع أي إصدار من Node.js. إذا كنت تستخدم mise بالفعل لإدارة إصدار Node، فإن Aube يتناسب بنفس الطريقة.
اعتبارات واقعية
حالة البيتا. اعتبارًا من أبريل 2026، Aube هو الإصدار v1.0.0-beta.10. توضح الوثائق صراحةً: إنه يهدف إلى التوافق مع pnpm v11، ولكنه لم يتم اختباره بعد عبر العديد من المشاريع. تعامل معه كما تتعامل مع أي أداة سابقة للإصدار 1.0. قم بتشغيله محليًا أولاً، احتفظ بملف القفل الحالي الخاص بك، لا تراهن على خط أنابيب إصدار الإنتاج الخاص بك حتى ترى أنه يعمل لمدة شهر.
ما هو خارج النطاق. لا يكرر Aube عن قصد ما يفعله mise بالفعل. إدارة وقت التشغيل (env، runtime، setup، self-update) تنتمي إلى mise. بعض مساعدي حسابات التسجيل (whoami، token، owner، search، pkg، set-script) هي قوالب توافق توجهك إلى أمر npm بدلاً من ذلك. إذا كان سكريبت CI الخاص بك يستدعي أيًا من هذه، فاحتفظ بـ npm كبديل.
دعم المنصات. المثبت الموصى به هو mise، والذي يدعم macOS و Linux و Windows عبر WSL. يتوفر دعم Windows الأصلي عبر ملف tarball ولكنه في مرحلة مبكرة؛ تحقق من صفحة التثبيت للمصفوفة الحالية.
المجتمع. يمتلك المشروع خادم Discord (مرتبط بالصفحة الرئيسية) و 325 نجمة على GitHub وقت الكتابة. صغير ولكنه نشط. توفر Buildkite CI للمشروع، والذي يمكنك رؤيته في جذر المستودع.
الأسئلة الشائعة
ماذا تعني "aube"؟فجر، بالفرنسية. تُنطق "أوب". شعار المشروع هو "فجر جديد لتثبيتات Node".
هل Aube بديل مباشر لـ pnpm؟قريب. يستهدف التوافق مع pnpm v11 ويقرأ تنسيق ملف قفل pnpm. تنتقل معظم مهام سير العمل بنكهة pnpm دون تغييرات. بعض أوامر pnpm (إدارة وقت التشغيل، وبعض أدوات مساعدة التسجيل) هي خارج النطاق عمدًا لأنها تنتمي إلى أدوات أخرى.
هل يمكنني استخدام Aube في CI مع الاحتفاظ بـ pnpm محليًا؟نعم، كلا الاتجاهين يعملان. يقرأ Aube ويكتب pnpm-lock.yaml في مكانه، لذا يمكن للأداتين مشاركة ملف قفل. تبدأ الفرق عادة بالاتجاه المعاكس: Aube محليًا، pnpm في CI، حتى يشعر الجميع بالراحة.
كيف يقارن Aube بـ Bun؟في عمليات التثبيت الدافئة، Aube أسرع بحوالي 3 مرات من Bun لأن Bun يعيد التحقق من حالة أكبر قبل التثبيت. في عمليات التثبيت الباردة، يتفوق Bun قليلاً لأن مسار الجلب الخاص به محكم للغاية. يشحن Bun أيضًا وقت تشغيل JS؛ Aube هو أداة تثبيت فقط. إذا كنت تستخدم Node بالفعل، فلن تحتاج إلى وقت تشغيل Bun لاستخدام Aube. توفر مقارنة التخطيط المعزول بنمط pnpm سياقًا حول سبب أهمية خيارات التخطيط.
هل يعمل Aube على Windows؟عبر WSL، نعم. يعمل Windows الأصلي ولكنه في مرحلة مبكرة. يعد mise أسهل طريقة للتثبيت والتحديث على جميع أنظمة التشغيل الثلاثة.
هل Aube مفتوح المصدر؟نعم، مرخص بموجب MIT، الكود المصدري على GitHub.
ماذا يحدث لملف pnpm-lock.yaml الحالي الخاص بي؟يقرأه Aube، يقوم بالتثبيت، ويكتب نفس الملف مرة أخرى مع أي تغييرات في الحل. يرى زملاؤك في الفريق الذين يستخدمون pnpm فرقًا عاديًا في ملف القفل.
الخلاصة
بالنسبة لمعظم مشاريع Node في عام 2026، فإن خطوة التثبيت أبطأ مما ينبغي. Aube هو أسرع مدير حزم لـ Node.js في مسارات التثبيت الدافئة والأوامر المتكررة التي تهيمن على سير عمل المطورين الحقيقيين: 139 مللي ثانية لتثبيت CI لمشروع يحتوي على 1,400 حزمة، و 21 مللي ثانية لـ install && test عندما لا يتغير شيء، و 90٪ مساحة أقل على القرص عبر جهاز يحتوي على عدة مشاريع. يقرأ ملف القفل الحالي الخاص بك، ويأخذ الافتراضات الأمنية على محمل الجد، ويكلف سطر mise use aube واحدًا لتجربته.
إذا كنت تختبر بالفعل واجهات برمجة التطبيقات باستخدام عميل سريع ومحلي أولاً مثل Apidog، فإن Aube هو الجزء المطابق على جانب التثبيت. قم بتنزيل Apidog إذا لم تكن قد فعلت ذلك، وقم بإقرانه مع Aube لخدمة Node التالية الخاصة بك، وشاهد مدى إحكام حلقة التغذية الراجعة.
