NestJS — Node.js للمؤسسات

المزوّدات غير المتزامنة ونطاقات الحقن

18 دقيقة الدرس 52 من 80

المزوّدات غير المتزامنة ونطاقات الحقن

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

الفكرة الأساسية

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

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

مثال عملي

يوضح المثال التالي الشكل العملي للفكرة داخل مشروع NestJS. ليست الغاية حفظ الكود، بل فهم مكانه في المعمارية:

const RedisClientProvider = { provide: REDIS_CLIENT, inject: [ConfigService], useFactory: async (config: ConfigService) => { const client = createClient({ url: config.getOrThrow('REDIS_URL') }); await client.connect(); return client; }, }; @Injectable({ scope: Scope.REQUEST }) export class RequestAuditContext { readonly id = randomUUID(); }
ملاحظة تصميمية: المزوّدات غير المتزامنة ممتازة لعملاء البنية التحتية. نطاق الطلب ليس بديلاً عن تمرير بيانات المستخدم أو المستأجر صراحة؛ استخدمه فقط عندما يجعل كائن حقيقي لكل طلب التصميم أبسط.

قائمة تطبيق إنتاجية

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

الخلاصة

يغطي هذا الدرس جزءاً متقدماً من NestJS يجب فهمه عند بناء تطبيقات مؤسسية. ركّز على الحدود الواضحة، والسلوك القابل للاختبار، واختيار الأداة المناسبة للسياق بدلاً من استخدام كل ميزة في كل مكان.