سياق JavaScript غير المتزامن: شرح مبسط للمتغيرات المرتبطة بنطاق الطلب

تُعد البرمجة غير المتزامنة حجر الزاوية في JavaScript الحديثة، خاصة في بيئات مثل Node.js حيث تكون معالجة الطلبات المتزامنة أمرًا بالغ الأهمية. ومع ذلك، يمكن أن تصبح إدارة الحالة والتبعيات عبر العمليات غير المتزامنة معقدة بسرعة. تقدم المتغيرات المرتبطة بنطاق الطلب، والتي يمكن الوصول إليها طوال دورة حياة طلب واحد، حلاً قويًا. تتعمق هذه المقالة في مفهوم سياق JavaScript غير المتزامن، مع التركيز على المتغيرات المرتبطة بنطاق الطلب وتقنيات إدارتها بفعالية. سنستكشف أساليب مختلفة، من الوحدات النمطية الأصلية إلى مكتبات الطرف الثالث، مع تقديم أمثلة عملية ورؤى لمساعدتك في بناء تطبيقات قوية وقابلة للصيانة.

فهم السياق غير المتزامن في JavaScript

إن طبيعة JavaScript أحادية الخيط، إلى جانب حلقة الأحداث (event loop)، تسمح بالعمليات غير الحاجبة (non-blocking). هذه الطبيعة غير المتزامنة ضرورية لبناء تطبيقات سريعة الاستجابة. ومع ذلك، فإنها تفرض أيضًا تحديات في إدارة السياق. في البيئة المتزامنة، تكون المتغيرات محصورة بشكل طبيعي داخل الدوال والكتل البرمجية. على النقيض من ذلك، يمكن أن تتوزع العمليات غير المتزامنة عبر دوال متعددة وتكرارات حلقة الأحداث، مما يجعل من الصعب الحفاظ على سياق تنفيذ متسق.

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

ما هي المتغيرات المرتبطة بنطاق الطلب؟

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

فيما يلي بعض حالات الاستخدام الرئيسية:

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

أساليب تنفيذ المتغيرات المرتبطة بنطاق الطلب

يمكن استخدام عدة أساليب لتنفيذ المتغيرات المرتبطة بنطاق الطلب في JavaScript. لكل نهج مفاضلاته الخاصة من حيث التعقيد والأداء والتوافق. دعنا نستكشف بعض التقنيات الأكثر شيوعًا.

1. التمرير اليدوي للسياق

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

مثال:

function handleRequest(req, res) {
  const userId = authenticateUser(req);
  processData(userId, req, res);
}

function processData(userId, req, res) {
  fetchDataFromDatabase(userId, (err, data) => {
    if (err) {
      return handleError(err, req, res);
    }
    renderResponse(data, userId, req, res);
  });
}

function renderResponse(data, userId, req, res) {
  // استخدام userId لتخصيص الاستجابة
  res.end(`Hello, user ${userId}! Data: ${JSON.stringify(data)}`);
}

كما ترى، نحن نمرر `userId` و `req` و `res` يدويًا إلى كل دالة. يصبح هذا الأمر صعب الإدارة بشكل متزايد مع تدفقات غير متزامنة أكثر تعقيدًا.

العيوب:

• الكود المتكرر (Boilerplate): يؤدي تمرير السياق بشكل صريح إلى كل دالة إلى إنشاء الكثير من الكود المكرر.
• عرضة للخطأ: من السهل نسيان تمرير السياق، مما يؤدي إلى أخطاء برمجية.
• صعوبات إعادة الهيكلة (Refactoring): يتطلب تغيير السياق تعديل توقيع كل دالة.
• الاقتران الوثيق (Tight coupling): تصبح الدوال مرتبطة بشكل وثيق بالسياق المحدد الذي تتلقاه.

2. AsyncLocalStorage (Node.js v14.5.0+)

قدم Node.js `AsyncLocalStorage` كآلية مدمجة لإدارة السياق عبر العمليات غير المتزامنة. يوفر طريقة لتخزين البيانات التي يمكن الوصول إليها طوال دورة حياة مهمة غير متزامنة. هذا هو النهج الموصى به بشكل عام لتطبيقات Node.js الحديثة. يعمل `AsyncLocalStorage` عبر دوال `run` و `enterWith` لضمان نشر السياق بشكل صحيح.

مثال:

const { AsyncLocalStorage } = require('async_hooks');

const asyncLocalStorage = new AsyncLocalStorage();

function handleRequest(req, res) {
  const requestId = generateRequestId();
  asyncLocalStorage.run(new Map(), () => {
    asyncLocalStorage.getStore().set('requestId', requestId);
    asyncLocalStorage.getStore().set('request', req);
    processData(res);
  });
}

function processData(res) {
  fetchDataFromDatabase((err, data) => {
    if (err) {
      return handleError(err, res);
    }
    renderResponse(data, res);
  });
}

function fetchDataFromDatabase(callback) {
  const requestId = asyncLocalStorage.getStore().get('requestId');
  // ... جلب البيانات باستخدام معرّف الطلب للتسجيل/التتبع
  setTimeout(() => {
    callback(null, { message: 'Data from database' });
  }, 100);
}

function renderResponse(data, res) {
  const requestId = asyncLocalStorage.getStore().get('requestId');
  res.end(`Request ID: ${requestId}, Data: ${JSON.stringify(data)}`);
}

في هذا المثال، تنشئ `asyncLocalStorage.run` سياقًا جديدًا (ممثلاً بـ `Map`) وتنفذ الدالة الممررة لها ضمن هذا السياق. يتم تخزين `requestId` في السياق ويمكن الوصول إليه في `fetchDataFromDatabase` و `renderResponse` باستخدام `asyncLocalStorage.getStore().get('requestId')`. يتم إتاحة `req` بالمثل. تغلف الدالة المجهولة المنطق الرئيسي. سترث أي عملية غير متزامنة داخل هذه الدالة السياق تلقائيًا.

المزايا:

• مدمج: لا حاجة إلى تبعيات خارجية في إصدارات Node.js الحديثة.
• نشر السياق التلقائي: يتم نشر السياق تلقائيًا عبر العمليات غير المتزامنة.
• السلامة النوعية (Type safety): يمكن أن يساعد استخدام TypeScript في تحسين السلامة النوعية عند الوصول إلى متغيرات السياق.
• فصل واضح للمسؤوليات: لا تحتاج الدوال إلى أن تكون على دراية صريحة بالسياق.

العيوب:

• يتطلب Node.js v14.5.0 أو أحدث: الإصدارات الأقدم من Node.js غير مدعومة.
• عبء أداء طفيف: هناك عبء أداء صغير مرتبط بتبديل السياق.
• إدارة يدوية للتخزين: تتطلب دالة `run` تمرير كائن تخزين، لذلك يجب إنشاء كائن `Map` أو ما شابه لكل طلب.

3. cls-hooked (التخزين المحلي المستمر)

`cls-hooked` هي مكتبة توفر التخزين المحلي المستمر (CLS)، مما يسمح لك بربط البيانات بسياق التنفيذ الحالي. لقد كانت خيارًا شائعًا لإدارة المتغيرات المرتبطة بنطاق الطلب في Node.js لسنوات عديدة، قبل ظهور `AsyncLocalStorage` الأصلي. بينما يُفضل الآن `AsyncLocalStorage` بشكل عام، تظل `cls-hooked` خيارًا قابلاً للتطبيق، خاصة بالنسبة لقواعد الكود القديمة أو عند دعم إصدارات Node.js الأقدم. ومع ذلك، ضع في اعتبارك أن لها آثارًا على الأداء.

مثال:

const cls = require('cls-hooked');
const namespace = cls.createNamespace('my-app');
const { v4: uuidv4 } = require('uuid');

cls.getNamespace = () => namespace;

const express = require('express');
const app = express();

app.use((req, res, next) => {
  namespace.run(() => {
    const requestId = uuidv4();
    namespace.set('requestId', requestId);
    namespace.set('request', req);
    next();
  });
});

app.get('/', (req, res) => {
  const requestId = namespace.get('requestId');
  console.log(`Request ID: ${requestId}`);
  res.send(`Hello, Request ID: ${requestId}`);
});

app.get('/data', (req, res) => {
  const requestId = namespace.get('requestId');

  setTimeout(() => {
    // محاكاة عملية غير متزامنة
    console.log(`Asynchronous operation - Request ID: ${requestId}`);
    res.send(`Data, Request ID: ${requestId}`);
  }, 500);
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

في هذا المثال، تنشئ `cls.createNamespace` مساحة اسم (namespace) لتخزين البيانات المرتبطة بنطاق الطلب. تقوم البرمجية الوسيطة (middleware) بتغليف كل طلب في `namespace.run`، والتي تنشئ السياق للطلب. تخزن `namespace.set` `requestId` في السياق، وتسترجعه `namespace.get` لاحقًا في معالج الطلب وأثناء العملية غير المتزامنة المحاكاة. يتم استخدام UUID لإنشاء معرّفات طلبات فريدة.

المزايا:

• مستخدمة على نطاق واسع: كانت `cls-hooked` خيارًا شائعًا لسنوات عديدة ولديها مجتمع كبير.
• واجهة برمجة تطبيقات بسيطة (API): الواجهة سهلة الاستخدام والفهم نسبيًا.
• تدعم إصدارات Node.js الأقدم: متوافقة مع الإصدارات الأقدم من Node.js.

العيوب:

• عبء على الأداء: تعتمد `cls-hooked` على تقنية monkey-patching، والتي يمكن أن تسبب عبئًا على الأداء. يمكن أن يكون هذا كبيرًا في التطبيقات ذات الإنتاجية العالية.
• احتمالية التعارض: يمكن أن تتعارض تقنية monkey-patching مع مكتبات أخرى.
• مخاوف الصيانة: بما أن `AsyncLocalStorage` هو الحل الأصلي، فمن المرجح أن يتركز جهد التطوير والصيانة المستقبلي عليه.

4. Zone.js

Zone.js هي مكتبة توفر سياق تنفيذ يمكن استخدامه لتتبع العمليات غير المتزامنة. على الرغم من أنها معروفة بشكل أساسي لاستخدامها في Angular، إلا أنه يمكن استخدام Zone.js أيضًا في Node.js لإدارة المتغيرات المرتبطة بنطاق الطلب. ومع ذلك، فهي حل أكثر تعقيدًا وثقلاً مقارنة بـ `AsyncLocalStorage` أو `cls-hooked`، ولا يوصى بها بشكل عام إلا إذا كنت تستخدم Zone.js بالفعل في تطبيقك.

المزايا:

• سياق شامل: توفر Zone.js سياق تنفيذ شاملًا جدًا.
• التكامل مع Angular: تكامل سلس مع تطبيقات Angular.

العيوب:

• التعقيد: Zone.js مكتبة معقدة ذات منحنى تعلم حاد.
• عبء على الأداء: يمكن أن تسبب Zone.js عبئًا كبيرًا على الأداء.
• مبالغ فيها للمتغيرات البسيطة المرتبطة بالطلب: هي حل مبالغ فيه لإدارة المتغيرات البسيطة المرتبطة بنطاق الطلب.

5. وظائف البرمجيات الوسيطة (Middleware)

في أطر عمل تطبيقات الويب مثل Express.js، توفر وظائف البرمجيات الوسيطة (middleware) طريقة ملائمة لاعتراض الطلبات وتنفيذ الإجراءات قبل وصولها إلى معالجات المسارات. يمكنك استخدام البرمجيات الوسيطة لتعيين المتغيرات المرتبطة بنطاق الطلب وإتاحتها للبرمجيات الوسيطة اللاحقة ومعالجات المسارات. يتم دمج هذا بشكل متكرر مع إحدى الطرق الأخرى مثل `AsyncLocalStorage`.

مثال (باستخدام AsyncLocalStorage مع برمجية Express الوسيطة):

const express = require('express');
const { AsyncLocalStorage } = require('async_hooks');
const { v4: uuidv4 } = require('uuid');

const app = express();
const asyncLocalStorage = new AsyncLocalStorage();

// برمجية وسيطة لتعيين المتغيرات المرتبطة بنطاق الطلب
app.use((req, res, next) => {
  asyncLocalStorage.run(new Map(), () => {
    const requestId = uuidv4();
    asyncLocalStorage.getStore().set('requestId', requestId);
    asyncLocalStorage.getStore().set('request', req);
    next();
  });
});

// معالج المسار
app.get('/', (req, res) => {
  const requestId = asyncLocalStorage.getStore().get('requestId');
  res.send(`Hello! Request ID: ${requestId}`);
});

app.listen(3000, () => {
  console.log('Server listening on port 3000');
});

يوضح هذا المثال كيفية استخدام البرمجيات الوسيطة لتعيين `requestId` في `AsyncLocalStorage` قبل وصول الطلب إلى معالج المسار. يمكن لمعالج المسار بعد ذلك الوصول إلى `requestId` من `AsyncLocalStorage`.

المزايا:

• إدارة مركزية للسياق: توفر وظائف البرمجيات الوسيطة مكانًا مركزيًا لإدارة المتغيرات المرتبطة بنطاق الطلب.
• فصل واضح للمسؤوليات: لا تحتاج معالجات المسارات إلى المشاركة المباشرة في إعداد السياق.
• سهولة التكامل مع أطر العمل: وظائف البرمجيات الوسيطة مدمجة جيدًا مع أطر عمل تطبيقات الويب مثل Express.js.

العيوب:

• تتطلب إطار عمل: هذا النهج مناسب بشكل أساسي لأطر عمل تطبيقات الويب التي تدعم البرمجيات الوسيطة.
• تعتمد على تقنيات أخرى: عادةً ما تحتاج البرمجيات الوسيطة إلى دمجها مع إحدى التقنيات الأخرى (مثل `AsyncLocalStorage` أو `cls-hooked`) لتخزين السياق ونشره بالفعل.

أفضل الممارسات لاستخدام المتغيرات المرتبطة بنطاق الطلب

فيما يلي بعض أفضل الممارسات التي يجب مراعاتها عند استخدام المتغيرات المرتبطة بنطاق الطلب:

• اختر النهج الصحيح: حدد النهج الذي يناسب احتياجاتك على أفضل وجه، مع مراعاة عوامل مثل إصدار Node.js ومتطلبات الأداء والتعقيد. بشكل عام، يعد `AsyncLocalStorage` الآن الحل الموصى به لتطبيقات Node.js الحديثة.
• استخدم اصطلاح تسمية ثابت: استخدم اصطلاح تسمية ثابت للمتغيرات المرتبطة بنطاق الطلب لتحسين قابلية قراءة الكود وصيانته. على سبيل المثال، ابدأ جميع المتغيرات المرتبطة بالطلب بالبادئة `req_`.
• وثّق سياقك: وثّق بوضوح الغرض من كل متغير مرتبط بنطاق الطلب وكيفية استخدامه داخل التطبيق.
• تجنب تخزين البيانات الحساسة مباشرة: فكر في تشفير أو إخفاء البيانات الحساسة قبل تخزينها في سياق الطلب. تجنب تخزين الأسرار مثل كلمات المرور مباشرة.
• نظّف السياق: في بعض الحالات، قد تحتاج إلى تنظيف السياق بعد معالجة الطلب لتجنب تسرب الذاكرة أو مشكلات أخرى. مع `AsyncLocalStorage`، يتم مسح السياق تلقائيًا عند اكتمال دالة `run`، ولكن مع أساليب أخرى مثل `cls-hooked`، قد تحتاج إلى مسح مساحة الاسم بشكل صريح.
• كن واعيًا بالأداء: كن على دراية بالآثار المترتبة على الأداء لاستخدام المتغيرات المرتبطة بنطاق الطلب، خاصة مع الأساليب التي تعتمد على monkey-patching مثل `cls-hooked`. اختبر تطبيقك جيدًا لتحديد ومعالجة أي اختناقات في الأداء.
• استخدم TypeScript للسلامة النوعية: إذا كنت تستخدم TypeScript، فاستفد منه لتحديد بنية سياق الطلب الخاص بك وضمان السلامة النوعية عند الوصول إلى متغيرات السياق. هذا يقلل من الأخطاء ويحسن قابلية الصيانة.
• فكر في استخدام مكتبة تسجيل: ادمج المتغيرات المرتبطة بنطاق الطلب مع مكتبة تسجيل لتضمين معلومات السياق تلقائيًا في رسائل السجل الخاصة بك. هذا يسهل تتبع الطلبات وتصحيح الأخطاء. تدعم مكتبات التسجيل الشائعة مثل Winston و Morgan نشر السياق.
• استخدم معرّفات الارتباط (Correlation IDs) للتتبع الموزع: عند التعامل مع الخدمات المصغرة أو الأنظمة الموزعة، استخدم معرّفات الارتباط لتتبع الطلبات عبر خدمات متعددة. يمكن تخزين معرّف الارتباط في سياق الطلب ونشره إلى خدمات أخرى باستخدام ترويسات HTTP أو آليات أخرى.

أمثلة من الواقع العملي

دعنا نلقي نظرة على بعض الأمثلة الواقعية لكيفية استخدام المتغيرات المرتبطة بنطاق الطلب في سيناريوهات مختلفة:

• تطبيق التجارة الإلكترونية: في تطبيق للتجارة الإلكترونية، يمكنك استخدام المتغيرات المرتبطة بنطاق الطلب لتخزين معلومات حول عربة تسوق المستخدم، مثل العناصر الموجودة في العربة، وعنوان الشحن، وطريقة الدفع. يمكن الوصول إلى هذه المعلومات من قبل أجزاء مختلفة من التطبيق، مثل كتالوج المنتجات، وعملية الدفع، ونظام معالجة الطلبات.
• تطبيق مالي: في تطبيق مالي، يمكنك استخدام المتغيرات المرتبطة بنطاق الطلب لتخزين معلومات حول حساب المستخدم، مثل رصيد الحساب، وسجل المعاملات، والمحفظة الاستثمارية. يمكن الوصول إلى هذه المعلومات من قبل أجزاء مختلفة من التطبيق، مثل نظام إدارة الحسابات، ومنصة التداول، ونظام التقارير.
• تطبيق الرعاية الصحية: في تطبيق للرعاية الصحية، يمكنك استخدام المتغيرات المرتبطة بنطاق الطلب لتخزين معلومات حول المريض، مثل التاريخ الطبي للمريض، والأدوية الحالية، والحساسية. يمكن الوصول إلى هذه المعلومات من قبل أجزاء مختلفة من التطبيق، مثل نظام السجلات الصحية الإلكترونية (EHR)، ونظام وصف الأدوية، ونظام التشخيص.
• نظام إدارة المحتوى العالمي (CMS): قد يقوم نظام إدارة المحتوى الذي يتعامل مع محتوى بلغات متعددة بتخزين اللغة المفضلة للمستخدم في متغيرات مرتبطة بنطاق الطلب. يسمح هذا للتطبيق بتقديم المحتوى تلقائيًا باللغة الصحيحة طوال جلسة المستخدم. وهذا يضمن تجربة محلية تحترم تفضيلات لغة المستخدم.
• تطبيق SaaS متعدد المستأجرين: في تطبيق البرمجيات كخدمة (SaaS) الذي يخدم مستأجرين متعددين، يمكن تخزين معرّف المستأجر (tenant ID) في متغيرات مرتبطة بنطاق الطلب. يسمح هذا للتطبيق بعزل البيانات والموارد لكل مستأجر، مما يضمن خصوصية البيانات وأمانها. هذا أمر حيوي للحفاظ على سلامة بنية متعددة المستأجرين.

الخاتمة

تُعد المتغيرات المرتبطة بنطاق الطلب أداة قيمة لإدارة الحالة والتبعيات في تطبيقات JavaScript غير المتزامنة. من خلال توفير آلية لعزل البيانات بين الطلبات المتزامنة، فإنها تساعد على ضمان سلامة البيانات، وتحسين قابلية صيانة الكود، وتبسيط عملية تصحيح الأخطاء. في حين أن التمرير اليدوي للسياق ممكن، إلا أن الحلول الحديثة مثل `AsyncLocalStorage` في Node.js توفر طريقة أكثر قوة وكفاءة للتعامل مع السياق غير المتزامن. إن اختيار النهج الصحيح بعناية، واتباع أفضل الممارسات، ودمج المتغيرات المرتبطة بنطاق الطلب مع أدوات التسجيل والتتبع يمكن أن يعزز بشكل كبير جودة وموثوقية كود JavaScript غير المتزامن الخاص بك. يمكن أن تصبح السياقات غير المتزامنة مفيدة بشكل خاص في معماريات الخدمات المصغرة.

مع استمرار تطور نظام JavaScript البيئي، يعد البقاء على اطلاع بأحدث التقنيات لإدارة السياق غير المتزامن أمرًا بالغ الأهمية لبناء تطبيقات قابلة للتطوير والصيانة والقوة. يقدم `AsyncLocalStorage` حلاً نظيفًا وعالي الأداء للمتغيرات المرتبطة بنطاق الطلب، ويوصى بشدة باعتماده للمشاريع الجديدة. ومع ذلك، فإن فهم المفاضلات بين الأساليب المختلفة، بما في ذلك الحلول القديمة مثل `cls-hooked`، مهم لصيانة وترحيل قواعد الكود الحالية. تبنَّ هذه التقنيات لترويض تعقيدات البرمجة غير المتزامنة وبناء تطبيقات JavaScript أكثر موثوقية وكفاءة لجمهور عالمي.