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

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

تكون لغات البرمجة متزامنةً عادةً، وتوفِّر بعضها طريقةً لإدارة عدم التزامن في اللغة نفسها أو من خلال المكتبات، فاللغات C و Java و C#‎ و PHP و Go و Ruby و Swift و Python متزامنة افتراضيًا، كما تعالجِ بعضها عدم التزامن باستخدام الخيوط threads، مما ينتج عنه عملية جديدة، فلغة جافاسكربت متزامنة افتراضيًا وتعمل على خيط وحيد، وهذا يعني أنّ الشيفرة لا يمكنها إنشاء خيوط جديدة وتشغيلها على التوازي، إذ تُنفَّذ سطور الشيفرة تسلسليًا سطرًا تلو الآخر كما في المثال التالي:

const a = 1
const b = 2
const c = a * b
console.log(c)
doSomething()

نشأت جافاسكربت داخل المتصفح، وكانت وظيفتها الرئيسية في البداية الاستجابة لإجراءات المستخدِم مثل onClick وonMouseOver وonChange وonSubmit وما إلى ذلك، ولكن بيئتها ساعدتها في التعامل مع نمط البرمجة المتزامن من خلال المتصفح الذي يوفّر مجموعةً من واجهات برمجة التطبيقات APIs التي يمكنها التعامل مع هذا النوع من العمليات، كما قدّم Node.js في الآونة الأخيرة بيئة إدخال/إخراج دون توقف لتوسيع هذا المفهوم ليشمل الوصول إلى الملفات واستدعاءات الشبكة وغير ذلك.

دوال رد النداء Callbacks

لا يمكنك معرفة الوقت الذي سينقر فيه المستخدِم على زر، لذلك تعرِّف معالج أحداث لحدث النقر الذي يقبل دالةً تُستدعَى عند بدء الحدث كما يلي:

document.getElementById('button').addEventListener('click', () => {
  //نُقِر العنصر
})

وهذا ما يسمى دالة رد النداء، وهي دالة بسيطة تُمرَّر على أساس قيمة إلى دالة أخرى وستُنفَّذ عند وقوع الحدث فقط، إذ يمكن ذلك لأن للغة جافاسكربت دوالًا من الصنف الأول، والتي يمكن إسنادها للمتغيرات وتمريرها إلى دوال أخرى تسّمى دوال الترتيب الأعلى higher-order functions، كما تُغلَّف شيفرة العميل في مستمع حدث load على الكائن window الذي يشغِّل دالة رد النداء عندما تكون الصفحة جاهزة فقط مثل المثال التالي:

window.addEventListener('load', () => {
  //حُمِّلت الصفحة
  //افعل ما تريده
})

تُستخدَم دوال رد النداء في كل مكان، ولا تقتصر على أحداث DOM فقط، فأحد الأمثلة الشائعة هو استخدام المؤقتات:

setTimeout(() => {
  // تشغيل بعد 2 ثانية
}, 2000)

تقبَل طلبات XHR دالة رد نداء عن طريق إسناد دالة لخاصية في المثال التالي، إذ ستُستدعَى هذه الدالة عند وقوع حدث معيّن -أي حدث تغيّرات حالة الطلب في مثالنا-:

const xhr = new XMLHttpRequest()
xhr.onreadystatechange = () => {
  if (xhr.readyState === 4) {
    xhr.status === 200 ? console.log(xhr.responseText) : console.error('error')
  }
}
xhr.open('GET', 'https://yoursite.com')
xhr.send()

معالجة الأخطاء في دوال رد النداء

تتمثَّل إحدى الإستراتيجيات الشائعة جدًا في استخدام ما يعتمده Node.js وهو المعامل الأول في أيّ دالة رد نداء هي كائن الخطأ، وبالتالي تُسمّى دوال رد النداء مع معامل الأخطاء الأول error-first callbacks، فإذا لم يكن هناك خطأً، فستكون قيمة الكائن null، وإذا كان هناك خطأ، فسيحتوي هذا الكائن وصفًا للخطأ ومعلومات أخرى.

fs.readFile('/file.json', (err, data) => {
  if (err !== null) {
    //عالِج الخطأ
    console.log(err)
    return
  }
  //لا يوجد خطأ، إذَا عالِج البيانات
  console.log(data)
})

مشكلة دوال رد النداء

تُعَدّ دوال رد النداء رائعةً في الحالات البسيطة، ولكن تضيف كل دالة رد نداء مستوىً من التداخل nesting، وبالتالي تتعقَّد الشيفرة بسرعة كبيرة عند وجود كثير من دوال رد النداء كما يلي:

window.addEventListener('load', () => {
  document.getElementById('button').addEventListener('click', () => {
    setTimeout(() => {
      items.forEach(item => {
        //أضِف شيفرتك هنا
      })
    }, 2000)
  })
})

تُعَدّ الشيفرة السابقة بسيطةً، إذ تتألف من 4 مستويات فقط، لكنك قد تصادف مستويات أكثر بكثير من التداخل وبالتالي سيزداد تعقيد الشيفرة.

بدائل دوال رد النداء

قدّمت جافاسكربت بدءًا من الإصدار ES6 ميزات متعددةً تساعدنا في التعامل مع الشيفرة غير المتزامنة التي لا تتضمن استخدام دوال رد النداء مثل:

• الوعود Promises في الإصدار ES6.
• صيغة عدم التزامن/الانتظار Async/Await في الإصدار ES8.

الوعود Promises

الوعود هي إحدى طرق التعامل مع الشيفرات غير المتزامنة في جافاسكربت دون كتابة كثير من دوال رد النداء في الشيفرة.

مدخل إلى الوعود

يُعرَّف الوعد Promise عمومًا على أنه وكيل لقيمة ستتوفر في وقت لاحق، فالوعود موجودة منذ سنوات، لكن وُحِّدت وقُدِّمت في الإصدار ES2015، واُستبدِلت دوال عدم التزامن Async functions في الإصدار ES2017 بها والتي تستخدِم واجهة برمجة تطبيقات الوعود أساسًا لها، لذلك يُعَدّ فهم الوعود أمرًا أساسيًا حتى في حالة استخدام دوال عدم التزامن في الشيفرة الأحدث عوضًا عن الوعود، وإليك شرح مختصر عن كيفية عمل الوعود.

يبدأ الوعد عند استدعائه في حالة انتظار pending state، أي أن الدالة المستدعِية تواصل التنفيذ في الوقت الذي تنتظر به الوعد لينفّذ معالجته الخاصة ويستجيب لها، حيث تنتظر الدالة المستدعِية إما إعادة الوعد في حالة التأكيد أو الحل resolved state أو في حالة الرفض rejected state، ولكن لغة جافاسكربت غير متزامنة، لذلك تتابع الدالة تنفيذها ريثما ينتهي الوعد من عمله، كما تستخدِم واجهات برمجة تطبيقات الويب المعيارية الحديثة الوعود بالإضافة إلى شيفرتك ومكتباتها، ومن هذه الواجهات البرمجية:

• Battery API.
• Fetch API.
• Service Workers.

ستستخدَم الوعود بالتأكيد في جافاسكربت الحديثة، لذلك يجب فهمها جيدًا.

إنشاء وعد

تُظهِر واجهة برمجة الوعد Promise API باني وعد Promise constructor يمكن تهيئته باستخدام الدالة new Promise()‎:

let done = true
const isItDoneYet = new Promise(
  (resolve, reject) => {
    if (done) {
      const workDone = 'Here is the thing I built'
      resolve(workDone)
    } else {
      const why = 'Still working on something else'
      reject(why)
    }
  }
)

يتحقّق الوعد من الثابت العام done، فإذا كانت قيمته صحيحة true، فإننا نعيد قيمة وعد مؤكَّد، وإلا فسنعيد وعدًا مرفوضًا، كما يمكننا إعادة قيمة باستخدام القيم resolve وreject، حيث أعدنا سلسلةً نصيةً فقط في المثال السابق، لكنها يمكن أن تكون كائنًا أيضًا.

استهلاك وعد

لنرى الآن كيفية استهلاك أو استخدام وعد.

const isItDoneYet = new Promise(
  //...
)
const checkIfItsDone = () => {
  isItDoneYet
    .then((ok) => {
      console.log(ok)
    })
    .catch((err) => {
      console.error(err)
    })
}

سيؤدي تشغيل الدالة checkIfItsDone()‎ إلى تنفيذ الوعد isItDoneYet()‎ وستنتظر إلى أن يُؤكَّد الوعد باستخدام دالة رد النداء then، وإذا كان هناك خطأ، فستعالجه في دالة رد النداء catch.

إذا أردت مزامنة وعود مختلفة، فسيساعدك التابع Promise.all()‎ على تحديد قائمة وعود، وتنفيذ شيء ما عند تأكيد هذه الوعود جميعها، وإليك المثال التالي:

const f1 = fetch('/something.json')
const f2 = fetch('/something2.json')
Promise.all([f1, f2]).then((res) => {
  console.log('Array of results', res)
})
.catch((err) => {
  console.error(err)
})

تتيح لك صيغة إسناد الهدم destructuring assignment syntax الخاصة بالإصدار ES2015 تنفيذ ما يلي:

Promise.all([f1, f2]).then(([res1, res2]) => {
  console.log('Results', res1, res2)
})

ليس الأمر مقتصرًا على استخدام fetch بالطبع، إذ يمكنك استخدام أيّ وعد، كما يُشغَّل التابع Promise.race()‎ عند تأكيد أول وعد من الوعود التي تمرّرها إليه، ويشغِّل دالةَ رد النداء المصاحبة للوعد مرةً واحدةً فقط مع نتيجة الوعد الأول المُؤكَّد resolved، وإليك المثال التالي:

const first = new Promise((resolve, reject) => {
  setTimeout(resolve, 500, 'first')
})
const second = new Promise((resolve, reject) => {
  setTimeout(resolve, 100, 'second')
})
Promise.race([first, second]).then((result) => {
  console.log(result) // second
})

سلسلة الوعود Chaining promises

يمكن أن يُعاد وعدٌ إلى وعد آخر، وبالتالي ستنشأ سلسلة من الوعود، إذ تقدِّم واجهة Fetch API -وهي طبقة فوق واجهة برمجة تطبيقات XMLHttpRequest- مثالًا جيدًا عن سلسلة وعود، إذ يمكننا استخدام هذه الواجهة للحصول على مورد ووضع سلسلة من الوعود في طابور لتنفيذها عند جلب المورد، كما تُعَدّ واجهة Fetch API آليةً قائمةً على الوعود، حيث يكافئ استدعاءُ الدالة fetch()‎ تعريف وعد باستخدام new Promise()‎، وإليك المثال التالي عن كيفية سلسلة الوعود:

const status = (response) => {
  if (response.status >= 200 && response.status < 300) {
    return Promise.resolve(response)
  }
  return Promise.reject(new Error(response.statusText))
}

const json = (response) => response.json()

fetch('/todos.json')
  .then(status)
  .then(json)
  .then((data) => { console.log('Request succeeded with JSON response', data) })
  .catch((error) => { console.log('Request failed', error) })

نستدعي في المثال السابق التابع fetch()‎ للحصول على قائمة من عناصر TODO من ملف todos.json الموجود في نطاق الجذر، وننشئ سلسلة من الوعود، كما يعيد تشغيل التابع fetch()‎ استجابةً لها خاصيات منها:

• status وهي قيمة عددية تمثِّل رمز حالة HTTP.
• statusText وهي رسالة حالة تكون قيمتها OK إذا نجح الطلب.

تحتوي الاستجابة response أيضًا على تابع json()‎ الذي يعيد وعدًا سيُؤكد ويُربَط مع محتوى الجسم المُعالَج والمُحوَّل إلى JSON.

الوعد الأول في السلسلة هو الدالة التي حدّدناها وهي status()‎ التي تتحقق من حالة الاستجابة، فإذا لم تكن استجابةً ناجحةً -أي قيمتها بين 200 و299، فسترفِض الوعد، إذ ستؤدي هذه العملية إلى تخطي جميع الوعود المتسلسلة المدرجَة في سلسلة الوعود وستنتقل مباشرةً إلى تعليمة catch()‎ في الأسفل، مما يؤدي إلى تسجيل نص فشل الطلب Request failed مع رسالة الخطأ؛ أما إذا نجحت الاستجابة، فستُستدعَى دالة json()‎ التي حدّدناها، وبما أنّ الوعد السابق يعيد كائن الاستجابة response عند النجاح، فسنحصل عليه على أساس دخل للوعد الثاني، وبالتالي نُعيد بيانات JSON المُعالَجة في هذه الحالة، لذا فإن الوعد الثالث يتلقى JSON مباشرةً مع تسجيله ببساطة في الطرفية كما يلي:

.then((data) => {
  console.log('Request succeeded with JSON response', data)
})

معالجة الأخطاء

ألحقنا في المثال السابق تعليمة catch بسلسلة وعود، فإذا فشل أيّ شيء في سلسلة الوعود مسببًا خطأً أو رفض وعد، فسينتقل التحكم إلى أقرب تعلمية catch()‎ أسفل السلسلة.

new Promise((resolve, reject) => {
  throw new Error('Error')
})
  .catch((err) => { console.error(err) })

// أو

new Promise((resolve, reject) => {
  reject('Error')
})
  .catch((err) => { console.error(err) })

إذا ظهر خطأ ضمن تعليمة catch()‎، فيمكنك إلحاق تعليمة catch()‎ ثانية لمعالجة الخطأ وهلم جرًا وهذا ما يسمى بعملية معالجة توريث الأخطاء Cascading errors.

new Promise((resolve, reject) => {
  throw new Error('Error')
})
  .catch((err) => { throw new Error('Error') })
  .catch((err) => { console.error(err) })

إذا ظهر الخطأ Uncaught TypeError: undefined is not a promise في الطرفية، فتأكد من استخدام new Promise()‎ بدلًا من استخدام Promise()‎.

صيغة عدم التزامن/الانتظار async/await

تطوّرت لغة جافاسكربت في وقت قصير جدًا من دوال رد النداء callbacks إلى الوعود promises في الإصدار ES2015، وأصبحت لغة جافاسكربت غير المتزامنة منذ الإصدار ES2017 أبسط مع صيغة عدم التزامن/الانتظار async/await، فالدوال غير المتزامنة هي مزيج من الوعود والمولِّدات generators، وهي في الأساس ذات مستوىً أعلى من الوعود من ناحية التجريد، فصيغة async/await مبنية على الوعود.

سبب ظهور صيغة async/await هو أنها تقلل من الشيفرة التكرارية أو المتداولة boilerplate الموجودة في الوعود، وتقلّل من محدودية قيود عدم كسر السلسلة في تسلسل الوعود، فقد كان الهدف من تقديم الوعود في الإصدار ES2015 حلَّ مشكلة التعامل مع الشيفرة غير المتزامنة، وقد حلّت هذه المشكلة حقًا، ولكن كان واضحًا على مدار العامين اللذين فصلا بين الإصدارين ES2015 وES2017 أن الوعود ليست الحل النهائي.

اُستخدِمت الوعود لحل مشكلة جحيم دوال رد النداء callback hell الشهيرة، لكنها أدخلت التعقيد فيها بالإضافة إلى تعقيد الصيغ، وقد كانت عناصرًا أوليةً جيدةً يمكن من خلالها إظهار صيغة أفضل للمطورين، لذلك حصلنا على دوال غير متزامنة في الوقت المناسب، إذ تظهر الشيفرة على أنها متزامنة، لكنها غير متزامنة وغير قابلة للتوقّف non-blocking في الحقيقة.

كيفية عمل صيغة async/await

تعيد الدالة غير المتزامنة وعدًا كما في المثال التالي:

const doSomethingAsync = () => {
  return new Promise((resolve) => {
    setTimeout(() => resolve('I did something'), 3000)
  })
}

إذا أردت استدعاء هذه الدالة، فستضيف الكلمة await في البداية، وستتوقف شيفرة الاستدعاء حتى تأكيد أو رفض الوعد.

اقتباس

تحذير: يجب تعريف دالة العميل على أنها غير متزامنة async.

إليك المثال التالي:

const doSomething = async () => {
  console.log(await doSomethingAsync())
}

إليك المثال التالي أيضًا والذي يوضِّح استخدام صيغة async/await لتشغيل دالة تشغيلًا غير متزامن:

const doSomethingAsync = () => {
  return new Promise((resolve) => {
    setTimeout(() => resolve('I did something'), 3000)
  })
}

const doSomething = async () => {
  console.log(await doSomethingAsync())
}

console.log('Before')
doSomething()
console.log('After')

ستطبع الشيفرة السابقة ما يلي في طرفية المتصفح:

Before
After
I did something //after 3s

تطبيق الوعود على كل شيء

تعني إضافة الكلمة المفتاحية async في بداية أيّ دالة أنّ هذه الدالة ستعيد وعدًا، وإذا لم تفعل ذلك صراحةً، فستعيد وعدًا داخليًا، وهذا سبب كون الشيفرة التالية صالحةً valid:

const aFunction = async () => {
  return 'test'
}

aFunction().then(alert) // سيؤدي هذا إلى تنبيه‫ 'test'

وكذلك الشيفرة التالية:

const aFunction = async () => {
  return Promise.resolve('test')
}

aFunction().then(alert) // سيؤدي هذا إلى تنبيه‫ 'test'

تبدو الشيفرة السابقة بسيطةً للغاية إذا وازنتها مع الشيفرة التي تستخدِم وعودًا صريحةً مع الدوال المتسلسلة ودوال رد النداء، كما يُعَدّ المثال السابق بسيطًا للغاية، لذلك ستظهر الفوائد جليةً عندما تكون الشيفرة أكثر تعقيدًا، وإليك المثال التالي الذي يوضّح كيفية الحصول على مورد JSON وتحليله parse باستخدام الوعود:

const getFirstUserData = () => {
  return fetch('/users.json') // الحصول على قائمة المستخدِمين
    .then(response => response.json()) // تحليل‫ JSON
    .then(users => users[0]) // التقاط المستخدِم الأول
    .then(user => fetch(`/users/${user.name}`)) // الحصول على بيانات المستخدِم
    .then(userResponse => response.json()) // تحليل‫ JSON
}
getFirstUserData()

وإليك المثال التالي الذي ينفّذ ما يفعله المثال السابق ولكن باستخدام صيغة await/async:

const getFirstUserData = async () => {
  const response = await fetch('/users.json') // الحصول على قائمة المستخدِمين
  const users = await response.json() // تحليل‫ JSON
  const user = users[0] // التقاط المستخدِم الأول
  const userResponse = await fetch(`/users/${user.name}`) // الحصول على بيانات المستخدِم
  const userData = await user.json() // تحليل‫ JSON
  return userData
}

getFirstUserData()

استخدام دوال متعددة غير متزامنة ضمن سلسلة

يمكن وضع الدوال غير المتزامنة ضمن سلسلة بسهولة باستخدام صيغة أكثر قابلية للقراءة من الوعود الصرفة كما يلي:

const promiseToDoSomething = () => {
  return new Promise(resolve => {
    setTimeout(() => resolve('I did something'), 10000)
  })
}

const watchOverSomeoneDoingSomething = async () => {
  const something = await promiseToDoSomething()
  return something + ' and I watched'
}

const watchOverSomeoneWatchingSomeoneDoingSomething = async () => {
  const something = await watchOverSomeoneDoingSomething()
  return something + ' and I watched as well'
}

watchOverSomeoneWatchingSomeoneDoingSomething().then((res) => {
  console.log(res)
})

ستطبع الشيفرة السابقة ما يلي:

I did something and I watched and I watched as well

سهولة تنقيح الأخطاء

يُعَدّ تنقيح أخطاء Debugging الوعود أمرًا صعبًا لأن منقِّح الأخطاء لن يتخطى الشيفرة غير المتزامنة، بينما تجعل صيغة Async/await هذا الأمر سهلًا لأنها تُعَدّ مجرد شيفرة متزامنة بالنسبة للمصرِّف compiler.

ترجمة -وبتصرّف- للفصل Asynchronous programming من كتاب The Node.js handbook لصاحبه Flavio Copes.

اقرأ أيضًا

• المقال التالي: التعامل مع الطلبيات الشبكية في Node.js
• المقال السابق: كيفية تنفيذ الدوال داخليا ضمن Node.js
• البرمجة غير المتزامنة في جافاسكريبت
• مقدّمة إلى البرمجة غير المتزامنة في Xamarin
• المدخل الشامل لتعلم علوم الحاسوب

سنتعرّف في هذا المقال على مفهوم حلقة الأحداث وكيفية سير عملية تنفيذ الدوال تنفيذًا غير متزامن ضمن نود، كما سنوضِّح كيفية التعامل مع الأحداث المخصَّصة من خلال الصنف EventEmitter الذي يُستخدَم لمعالجة الأحداث.

حلقة الأحداث event loop

تُعَدّ حلقة الأحداث Event Loop أحد أهم جوانب جافاسكربت التي يجب فهمها.

مدخل إلى حلقة الأحداث

اقتباس

توضيح: قد تكون مبرمج جافاسكربت منذ سنوات، ولكنك لم تفهم تمامًا كيفية سير الأمور الداخلية، إذ لا يُعَدّ عدم معرفتك بهذا المفهوم بالتفصيل عيبًا، ولكن معرفتك بذلك أمر جيد.

سنشرح التفاصيل الداخلية لكيفية عمل جافاسكربت باستخدام خيط thread واحد، وسنوضّح كيفية معالجة الدوال غير المتزامنة.

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

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

إيقاف حلقة الأحداث

ستوقِف شيفرة جافاسكربت التي تستغرق وقتًا طويلًا لإعادة التحكم إلى حلقة الأحداث مرةً أخرى تنفيذَ أيّ شيفرة جافاسكربت في الصفحة، إذ يمكن أن توقِف خيط واجهة المستخدِم، وبالتالي لا يمكن للمستخدِم تمرير الصفحة أو النقر عليها وغير ذلك، كما تُعَدّ جميع عناصر الدخل/الخرج الأولية في جافاسكربت غير قابلة للإيقاف non-blocking تقريبًا مثل طلبات الشبكة وعمليات نظام ملفات Node.js وما إلى ذلك، ولكن الاستثناء هو توقّفها، وهذا هو سبب اعتماد جافاسكربت الكبير على دوال رد النداء callbacks واعتمادها مؤخرًا على الوعود promises وصيغة عدم التزامن/الانتظار async/await.

مكدس الاستدعاءات call stack

مكدس الاستدعاءات هو طابور LIFO أي القادم أخيرًا يخرج أولًا Last In First Out، حيث تتحقّق حلقة الأحداث باستمرار من مكدس الاستدعاءات للتأكد من وجود دالة يجب تشغيلها، حيث تضيف حلقة الأحداث عندها أي استدعاء دالة تجده إلى مكدس الاستدعاءات وتنفّذ كل استدعاء بالترتيب.

قد تكون على دراية بتعقّب مكدس الأخطاء في منقِّح الأخطاء debugger أو في وحدة تحكم المتصفح، حيث يبحث المتصفح عن أسماء الدوال في مكدس الاستدعاءات لإعلامك بالدالة التي تنشئ الاستدعاء الحالي:

شرح بسيط لحلقة الأحداث

افترض المثال التالي:

const bar = () => console.log('bar')

const baz = () => console.log('baz')

const foo = () => {
 console.log('foo')
 bar()
 baz()
}
foo()

الذي يطبع ما يلي:

foo
bar
baz

تُستدعَى الدالة foo()‎ أولًا عند تشغيل الشيفرة السابقة، ثم نستدعي الدالة bar()‎ أولًا ضمن الدالة foo()‎، ثم نستدعي الدالة baz()‎، ويبدو مكدس الاستدعاءات في هذه المرحلة كما يلي:

تتأكد حلقة الأحداث في كل تكرار من وجود شيء ما في مكدس الاستدعاءات، وتنفِّذه كما يلي إلى أن يصبح مكدس الاستدعاءات فارغًا:

تنفيذ طابور الدوال

لا يوجد شيء مميز في المثال السابق، حيث تعثر شيفرة جافاسكربت على الدوال لتنفيذها وتشغيلها بالترتيب، ولنشاهد كيفية تأجيل تنفيذ دالة إلى أن يصبح المكدس فارغًا، حيث تُستخدَم حالة الاستخدام setTimeout(() => {}), 0)‎ لاستدعاء دالة، ولكنها تُنفَّذ عند كل تنفيذ لدالة أخرى في الشيفرة، وإليك المثال التالي:

const bar = () => console.log('bar')

const baz = () => console.log('baz')

const foo = () => {
 console.log('foo')
 setTimeout(bar, 0)
 baz()
}

foo()

تطبع الشيفرة السابقة ما يلي:

foo
baz
bar

تُستدعَى الدالة foo()‎ أولًا عند تشغيل الشيفرة، ثم نستدعي setTimeout أولًا ضمن الدالة foo()‎، ونمرّر bar على أساس وسيط، ونطلب منه العمل على الفور بأسرع ما يمكنه، ونمرر القيمة 0 على أساس مؤقت timer، ثم نستدعي الدالة baz()‎، حيث يبدو مكدس الاستدعاءات في هذه المرحلة كما يلي:

يوضِّح الشكل التالي ترتيب تنفيذ جميع الدوال في البرنامج:

طابور الرسائل Message Queue

يبدأ المتصفح أو Node.js المؤقت timer عند استدعاء الدالة setTimeout()‎، ثم توضَع دالة رد النداء callback function في طابور الرسائل Message Queue بمجرد انتهاء صلاحية المؤقت عالفور مثل حالة وضع القيمة 0 على أساس مهلة زمنية timeout.

يُعَدّ طابور الرسائل المكان الذي توضَع الأحداث التي بدأها المستخدِم مثل أحداث النقر أو أحداث لوحة المفاتيح أو جلب الاستجابات الموجودة في طابور قبل أن تتاح لشيفرتك فرصة الرد عليها أو أحداث DOM مثل onLoad.

اقتباس

ملاحظة: تعطِي الحلقة الأولوية لمكدّس الاستدعاءات، وتعالج كل شيء تجده فيه أولًا، ثم تنتقل لالتقاط الأشياء الموجودة في طابور الأحداث عند عدم وجود أي شيء في مكدّس الاستدعاءات.

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

طابور العمل Job Queue الخاص بالإصدار ES6

قدّم المعيار ECMAScript 2015 مفهوم طابور العمل Job Queue الذي تستخدمه الوعود Promises التي قُدِّمت أيضًا ضمن الإصدار ES6/ES2015، ويُعَدّ هذا المفهوم طريقةً لتنفيذ نتيجة دالة غير متزامنة بأسرع ما يمكن بدلًا من وضعها في نهاية مكدس الاستدعاءات.

ستُنفَّذ الوعود المؤكَّدة قبل انتهاء الدالة الحالية بعدها مباشرةً، حيث يشبه ذلك ركوب الأفعوانية في مدينة ملاهي، إذ يضعك طابور الرسائل بعد جميع الأشخاص الآخرين الموجودين في هذا الطابور، بينما طابور العمل هو مثل تذكرة Fastpass تتيح لك الركوب في رحلة أخرى في الأفعوانية بعد الانتهاء من الرحلة السابقة مباشرةً، وإليك المثال التالي:

const bar = () => console.log('bar')
const baz = () => console.log('baz')
const foo = () => {
 console.log('foo')
 setTimeout(bar, 0)
 new Promise((resolve, reject) =>
   resolve('should be right after baz, before bar')
 ).then(resolve => console.log(resolve))
 baz()
}
foo()

تطبع الشيفرة السابقة ما يلي:

foo
baz
should be right after baz, before bar
bar

يشكّل ذلك فرقًا كبيرًا بين الوعود Promises وصيغة Async/await المبنيّة على الوعود والدوال القديمة غير المتزامنة من خلال الدالة setTimeout()‎ أو واجهات API للمنصات الأخرى.

المؤقتات Timers: التنفيذ غير المتزامن في أقرب وقت ممكن

تُعَدّ الدالة process.nextTick()‎ جزءًا مهمًا من حلقة أحداث Node.js، حيث نسمّي كل دورة كاملة تدورها حلقة الأحداث بالاسم نبضة tick، كما يؤدي تمرير دالة إلى process.nextTick()‎ إلى استدعاء هذه الدالة في نهاية العملية الحالية وقبل بدء نبضة حلقة الأحداث التالية.

process.nextTick(() => {
 //افعل شيئًا ما
})

حلقة الأحداث مشغولة بمعالجة شيفرة الدالة الحالية، كما يشغّل محرك JS عند انتهاء هذه العملية جميع الدوال المُمرَّرة إلى استدعاءات nextTick خلال تلك العملية، وهي الطريقة التي يمكننا من خلالها إخبار محرك JS بمعالجة دالة بطريقة غير متزامنة بعد الدالة الحالية في أقرب وقت ممكن دون وضعها في طابور، كما سيؤدي استدعاء setTimeout(() => {}, 0)‎ إلى تنفيذ الدالة في النبضة التالية بعد وقت أطول من استخدام الدالة nextTick()‎، واستخدم الدالة nextTick()‎ عندما تريد التأكد من تنفيذ الشيفرة في تكرار حلقة الأحداث التالي.

الدالة setTimeout()‎

قد ترغب في تأخير تنفيذ دالة عند كتابة شيفرة جافاسكربت، وهذه هي مهمة الدالة setTimeout، حيث تحدِّد دالة رد نداء لتنفيذها لاحقًا مع قيمة تعبِّر عن مقدار التأخير لتشغيلها لاحقًا مقدَّرةً بالميلي ثانية:

setTimeout(() => {
 // تشغيل بعد 2 ثانية
}, 2000)
setTimeout(() => {
 // تشغيل بعد 50 ميلي ثانية
}, 50)

تحدِّد هذه الصيغة دالةً جديدةً، حيث يمكنك استدعاء أيّ دالة أخرى تريدها هناك، أو يمكنك تمرير اسم دالة موجودة مسبقًا مع مجموعة من المعاملات كما يلي:

const myFunction = (firstParam, secondParam) => {
 // افعل شيئًا ما
}
// تشغيل بعد 2 ثانية
setTimeout(myFunction, 2000, firstParam, secondParam)

تعيد الدالة setTimeout معرِّف المؤقت timer id، وهذا المعرِّف غير مُستخدَم، ولكن يمكنك تخزينه ومسحه إذا أردت حذف تنفيذ الدوال المجدولة:

const id = setTimeout(() => {
 // يجب تشغيله بعد 2 ثانية
}, 2000)
//غيّرنا رأينا
clearTimeout(id)

الدالة setImmediate

إذا أردت تنفيذ جزء من الشيفرة بطريقة غير متزامنة ولكن في أقرب وقت ممكن، فإنّ أحد الخيارات هو استخدام الدالة setImmediate()‎ التي يوفّرها Node.js:

setImmediate(() => {
 //شغّل شيئًا ما
})

تمثِّل الدالة المُرَّرة على أساس وسيط للدالة setImmediate()‎ دالةَ رد نداء تُنفَّذ في تكرار حلقة الأحداث التالي، كما تختلف setImmediate()‎ عن setTimeout(() => {}, 0)‎ مع تمرير مهلة زمنية مقدارها 0 ميلي ثانية وعن process.nextTick()‎، إذ تُنفَّذ الدالة المُمرَّرة إلى process.nextTick()‎ في تكرار حلقة الأحداث الحالي بعد انتهاء العملية الحالية، وهذا يعني أنها ستُنفَّذ دائمًا قبل setTimeout وsetImmediate، كما تشبه دالةُ رد النداء setTimeout()‎ مع تأخير 0 ميلي ثانية الدالةَ setImmediate()‎، في حين يعتمد ترتيب التنفيذ على عوامل مختلفة، ولكنهما ستُشغَّلان في تكرار حلقة الأحداث التالي.

التأخير الصفري Zero delay

إذا حدّدت تأخير المهلة الزمنية بالقيمة 0، فستُنفَّذ دالة رد النداء في أقرب وقت ممكن ولكن بعد تنفيذ الدالة الحالية:

setTimeout(() => {
 console.log('after ')
}, 0)
console.log(' before ')

ستطبع الدالة السابقة before after.

يُعَدّ هذا مفيدًا لتجنب إيقاف وحدة المعالجة المركزية CPU في المهام المكثفة والسماح بتنفيذ الدوال الأخرى أثناء إجراء عملية حسابية ثقيلة عن طريق وضع الدوال ضمن طابور في المجدوِل scheduler.

اقتباس

توضيح: تطبّق بعض المتصفحات مثل متصفح IE ومتصفح Edge دالة setImmediate()‎ التي تؤدي العملية نفسها، ولكنها ليست معيارًا وغير متوفرة في المتصفحات الأخرى، وإنما هي دالة معيارية في Node.js.

الدالة setInterval()‎

تُعَدّ setInterval دالةً مشابهةً للدالة setTimeout، مع اختلاف أنّ الدالة setInterval ستشغِّل دالةَ رد النداء إلى الأبد ضمن الفاصل الزمني الذي تحدِّده مقدَّرًا بالميلي ثانية بدلًا من تشغيلها مرةً واحدةً:

setInterval(() => {
 // تشغيل كل 2 ثانية
}, 2000)

تُشغَّل الدالة السابقة كل 2 ثانية ما لم تخبرها بالتوقف باستخدام clearInterval من خلال تمرير معرِّف id الفاصل الزمني الذي تعيده الدالة setInterval:

const id = setInterval(() => {
 // تشغيل كل 2 ثانية
}, 2000)
clearInterval(id)

يشيع استدعاء clearInterval ضمن دالة رد نداء الدالة setInterval، للسماح لها بالتحديد التلقائي إذا وجب تشغيلها مرةً أخرى أو إيقافها، حيث تشغّل الشيفرة التالية شيئًا على سبيل المثال إذا لم تكن قيمة App.somethingIWait هي arrived:

const interval = setInterval(() => {
 if (App.somethingIWait === 'arrived') {
   clearInterval(interval)
   return
 }
 // وإلّا افعل شيئًا ما
}, 100)

دالة setTimeout العودية

تبدأ setInterval دالةً كل n ميلي ثانية، دون الأخذ في الحسبان موعد انتهاء تنفيذ هذه الدالة، فإذا استغرقت الدالة القدر نفسه من الوقت دائمًا، فلا بأس بذلك:

قد تستغرق الدالة أوقات تنفيذ مختلفة اعتمادًا على ظروف الشبكة مثلًا:

وقد يتداخل وقت تنفيذ دالة طويل مع وقت تنفيذ الدالة التالية:

يمكن تجنب ذلك من خلال جدولة دالة setTimeout العودية لتُستدعَى عند انتهاء دالة رد النداء:

const myFunction = () => {
 // افعل شيئًا ما
 setTimeout(myFunction, 1000)
}
setTimeout(
 myFunction()
}, 1000)

بهدف تحقيق السيناريو التالي:

يتوفَّر كل من setTimeout وsetInterval في Node.js من خلال وحدة المؤقتات Timers module، كما يوفِّر Node.js أيضًا الدالة setImmediate()‎ التي تعادل استخدام setTimeout(() => {}, 0)‎ المستخدَمة للعمل مع حلقة أحداث Node.js في أغلب الأحيان.

مطلق الأحداث Event Emitter الخاص بنود Node

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

يوفِّر نود على جانب الواجهة الخلفية خيارًا لإنشاء نظام مماثل باستخدام وحدة الأحداث events module، إذ تقدّم هذه الوحدة الصنف EventEmitter الذي يُستخدَم لمعالجة الأحداث، كما يمكنك تهيئته كما يلي:

const eventEmitter = require('events').EventEmitter()

يُظهِر هذا الكائن التابعين on وemit من بين أشياء متعددة.

• emit الذي يُستخدَم لبدء حدث.
• on الذي يُستخدَم لإضافة دالة رد نداء والتي ستُنفَّذ عند بدء الحدث.

لننشئ حدث start مثلًا ثم نتفاعل معه من خلال تسجيل الدخول إلى الطرفية:

eventEmitter.on('start', () => {
 console.log('started')
})

فإذا شغّلنا ما يلي:

eventEmitter.emit('start')

فستُشغَّل دالة معالج الأحداث، وسنحصل على سجل طرفية.

يمكنك تمرير الوسائط إلى معالج الأحداث من خلال تمريرها على أساس وسائط إضافية إلى التابع emit()‎ كما يلي:

eventEmitter.on('start', (number) => {
 console.log(`started ${number}`)
})

eventEmitter.emit('start', 23)

أو من خلال تمرير وسائط متعددة كما يلي:

eventEmitter.on('start', (start, end) => {
 console.log(`started from ${start} to ${end}`)
})

eventEmitter.emit('start', 1, 100)

يظهِر كائن EventEmitter توابعًا متعددةً أخرى للتفاعل مع الأحداث مثل:

• once()‎: يضيف مستمعًا لمرة واحدة.
• removeListener()‎ أو off()‎: يزيل مستمع حدث من الحدث.
• removeAllListeners()‎: يزيل جميع المستمعين لحدث ما.

يمكنك قراءة جميع التفاصيل الخاصة بهذه التوابع في صفحة وحدة الأحداث events module على Node.js.

ترجمة -وبتصرّف- للفصل Working with the event loop من كتاب The Node.js handbook لصاحبه Flavio Copes.

اقرأ أيضًا

• المقال التالي: البرمجة غير المتزامنة في Node.js
• المقال السابق: دليلك الشامل إلى مدير الحزم npm في Node.js
• إعداد تطبيق node.js لسير عمل يعتمد على الحاويات باستخدام Docker Compose
• تأمين تطبيق Node.js يعمل على الحاويات باستخدام Nginx و Let’s Encrypt و Compose Docker
• استخدام الوضع التفاعلي والتعامل مع سطر الأوامر في Node.js

يمثِّل مدير حزم نود npm -اختصارًا إلى Node Package Manager- أساس نجاح Node.js، فقد صدر تقرير في شهر 1 من عام 2017 بوجود أكثر من 350000 حزمة مُدرجَة في سجل npm، مما يجعله أكبر مستودع لشيفرات لغة على الأرض، فكُن على ثقة أنك ستجد فيه حزمةً لكل شيء تقريبًا.

يُعَدّ npm مدير حزم Node.js المعياري، فقد اُستخدِم في البداية على أساس طريقة لتنزيل وإدارة اعتماديات حزم Node.js، لكنه أصبح بعدها أداةً تُستخدَم في واجهة جافاسكربت الأمامية أيضًا.

اقتباس

توضيح: يُعَدّ Yarn بديلًا عن npm.

إدارة تنزيل الحزم والمكتبات والاعتماديات

يدير npm تنزيلات جميع اعتماديات مشروعك.

تثبيت جميع الاعتماديات Dependencies

يمكنك استخدام الأمر التالي إذا احتوى المشروع على ملف packages.json:

npm install

سيثبِّت كل ما يحتاجه المشروع في المجلد node_modules مع إنشاء هذا المجلد إذا لم يكن موجودًا مسبقًا.

تثبيت حزمة واحدة

يمكنك أيضًا تثبيت حزمة معينة عن طريق تشغيل الأمر:

npm install <package-name>

سترى في أغلب الأحيان مزيدًا من الرايات flags المضافة إلى هذا الأمر مثل:

• ‎--save التي تثبّت وتضيف مدخلة إلى اعتماديات ملف package.json وهي الافتراضية فلا داعي لإضافتها في كل مرة تثبت فيها حزمة في مشروعك.
• ‎--save-dev التي تثبّت وتضيف مدخلة إلى اعتماديات تطوير devDependencies ملف package.json.

يتمثل الاختلاف الأساسي بينهما في أن اعتماديات التطوير devDependencis هي أدوات تطوير مثل مكتبة الاختبار، بينما تُجمَّع الاعتماديات dependencies مع التطبيق الذي يكون قيد الإنتاج.

يمكن تثبيت إصدار أقدم من حزمة npm أو تثبيت إصدار محدد بعينه، وهو شيء قد يكون مفيدًا في حل مشكلة التوافق، كما يمكنك تثبيت إصدار قديم من حزمة npm باستخدام صيغة @ كما يلي:

npm install <package>@<version>

يثبّت الأمر التالي الإصدار الإصدار الأخير الأحدث من حزمة cowsay:

npm install cowsay

يمكنك تثبيت الإصدار 1.2.0 من خلال الأمر التالي:

npm install cowsay@1.2.0

يمكن تطبيق الشيء نفسه مع الحزم العامة كما يلي:

npm install -g webpack@4.16.4

وقد تكون مهتمًا بسرد جميع إصدارات الحزمة السابقة من خلال استخدام الأمر npm view <package> versions كما يلي:

npm view cowsay versions

[  '1.0.0',
  '1.0.1',
  '1.0.2',
  '1.0.3',
  '1.1.0',
  '1.1.1',
  '1.1.2',
  '1.1.3',
  '1.1.4',
  '1.1.5',
  '1.1.6',
  '1.1.7',
  '1.1.8',
  '1.1.9',
  '1.2.0',
  '1.2.1',
  '1.3.0',
  '1.3.1' ]

مكان تثبيت npm للحزم

يمكنك إجراء نوعين من التثبيت، عند تثبيت حزمة باستخدام npm أو yarn:

• تثبيت محلي local install.
• تثبيت عام global install.

إذا كتبتَ أمر تثبيت npm install مثل الأمر التالي، فستُثبَّت الحزمة في شجرة الملفات الحالية ضمن المجلد الفرعي node_modules افتراضيًا، ويضيف عندها npm أيضًا المدخلة lodash في خاصية الاعتماديات dependencies الخاصة بملف package.json الموجود في المجلد الحالي:

npm install lodash

يُطبَّق التثبيت العام باستخدام الراية ‎-g:

npm install -g lodash

لن يثبِّت npm الحزمة ضمن المجلد المحلي وإنما سيستخدم موقعًا عامًا، إذ سيخبرك الأمر npm root -g بمكان هذا الموقع الدقيق على جهازك، حيث يمكن أن يكون هذا الموقع ‎/usr/local/lib/node_modules في نظام macOS أو لينكس، ويمكن أن يكون C:\Users\YOU\AppData\Roaming\npm\node_modules على نظام ويندوز، لكن إذا استخدمت nvm لإدارة إصدارات Node.js، فقد يختلف هذا الموقع، حيث استخدمنا nvm على سبيل المثال وكان موقع الحزم هو ‎/Users/flavio/.nvm/versions/node/v8.9.0/lib/node_modules.

كيفية استخدام أو تنفيذ حزمة مثبتة باستخدام npm

هل تساءلت عن كيفية تضمين واستخدام حزمة مثبَّتة في مجلد node_modules في شيفرتك الخاصة؟ حسنًا، لنفترض أنك ثبَّت مكتبة أدوات جافاسكربت الشائعة lodash باستخدام الأمر التالي:

npm install lodash

سيؤدي ذلك إلى تثبيت الحزمة في مجلد node_modules المحلي التي يمكنك استخدامها في شيفرتك الخاصة من خلال استيرادها في برنامجك باستخدام require:

const _ = require('lodash)

إذا كانت حزمتك الخاصة قابلة للتنفيذ، فسيوضَع الملف القابل للتنفيذ ضمن المجلد node_modules/.bin/‎، وإحدى طرق إثبات ذلك هي استخدام الحزمة cowsay، حيث توفِّر هذه الحزمة برنامج سطر أوامر يمكن تنفيذه لإنشاء بقرة تقول شيئًا -وحيوانات أخرى أيضًا-، حيث ستثبِّت هذه الحزمة نفسها وعددًا من الاعتماديات في المجلد node_modules عند تثبيتها باستخدام الأمر npm install cowsay:

يوجد مجلد ‎.bin‎‎ مخفي يحتوي على روابط رمزية إلى ملفات cowsay الثنائية:

يمكنك تنفيذ هذه الحزمة من خلال كتابة ‎./node_modules/.bin/cowsay لتشغيلها، لكن يُعَدّ npx المُضمَّن في الإصدارات الأخيرة من npm -منذ الإصدار 5.2- الخيار الأفضل، فما عليك إلا تشغيل الأمر التالي:

npx cowsay

وسيجد npx موقع الحزمة.

تحديث الحزم

أصبح التحديث سهلًا أيضًا عن طريق تشغيل الأمر:

npm update

سيتحقّق npm من جميع الحزم بحثًا عن إصدار أحدث يلبي قيود إدارة الأصدارات Versioning الخاصة بك، كما يمكنك تحديد حزمة واحدة لتحديثها أيضًا باستخدام الأمر:

npm update <package-name>

إذا أردت تحديث جميع اعتماديات npm المخزَّنة في الملف package.json -الذي سنشرحه بعد قليل- إلى أحدث إصدار متاح لها، فثبَّتَ حزمةً باستخدام الأمر npm install <packagename>‎ الذي سينزِّل أحدث إصدار متاح من الحزمة ويوضَع هذا الإصدار في مجلد node_modules، وستُضاف مدخلة مقابلة إلى الملف package.json والملف package-lock.json الموجودَين في مجلدك الحالي، إذ يحسب npm الاعتماديات ويثبّت أحدث إصدار متاح منها أيضًا.

لنفترض أنك ثبَّتَ الحزمة cowsay، وهي أداة سطر أوامر رائعة تتيح لك إنشاء بقرة تقول أشياء، فإذا ثبَّتَها باستخدام الأمر npm install cowsay، فستضاف المدخلة التالية إلى ملف package.json:

{
  "dependencies": {
     "cowsay": "^1.3.1"
  }
}

يمثّل ما يلي جزءًا من ملف package-lock.json، حيث أزلنا الاعتماديات المتداخلة للتوضيح:

{
  "requires": true,
  "lockfileVersion": 1,
  "dependencies": {
     "cowsay": {
        "version": "1.3.1",
        "resolved": "https://registry.npmjs.org/cowsay/-/cowsay-1.3.1.tgz",
        "integrity": "sha512-3PVFe6FePVtPj1HTeLin9v8WyLl+VmM1l1H/5P+BTTDkMAjufp+0F9eLjzRnOHzVAYeIYFF5po5NjRrgefnRMQ==",
        "requires": {
           "get-stdin": "^5.0.1",
           "optimist": "~0.6.1",
           "string-width": "~2.1.1",
           "strip-eof": "^1.0.0"
        }
     }
  }
}

يوضّح هذان الملفان أننا ثبَّتنا الإصدار 1.3.1 من الحزمة cowsay باستخدام قاعدة التحديثات ‎^1.3.1، والتي تعني بالنسبة لقواعد إدارة إصدارات npm أنه يمكن تحديث npm إلى إصدار حزمة التصحيح patch والإصدار الثانوي minor، أي 0.13.1 و0.14.0 وما إلى ذلك، فإذا كان هناك إصدار ثانوي أو إصدار حزمة تصحيح جديد وكتبنا الأمر npm update، فسيُحدَّث الإصدار المثبَّت، وسيُملَأ ملف package-lock.json بالإصدار الجديد، بينما يبقى الملف package.json دون تغيير، كما يمكنك اكتشاف إصدارات الحزم الجديدة من خلال تشغيل الأمر npm outdated، وفيما يلي قائمة ببعض الحزم القديمة في مستودع واحد لم نحدِّثها لفترة طويلة:

تُعَدّ بعض هذه التحديثات إصدارات رئيسية، إذ لن يؤدي تشغيل الأمر npm update إلى تحديثها، فالإصدارات الرئيسية لا تُحدَّث بهذه الطريقة أبدًا لأنها حسب التعريف تقدِّم تغييرات جذرية، ولأن npm يريد توفير المتاعب عليك، في حين يمكنك تحديث جميع الحزم إلى إصدار رئيسي جديد من خلال تثبيت الحزمة تثبيتًا عامًا باستخدام الأمر npm-check-updates كما يلي:

npm install -g npm-check-updates

ثم تشغيلها باستخدام الأمر التالي:

ncu -u

سيؤدي ذلك إلى ترقية جميع تلميحات الإصدار في ملف package.json إلى الاعتماديات dependencies وdevDependencies، لذلك يستطيع npm تثبيت الإصدار الرئيسي الجديد، ويمكنك الآن تشغيل أمر التحديث كما يلي:

npm update

إذا حمّلتَ المشروع بدون اعتماديات node_modules وأردت تثبيت الإصدارات الجديدة أولًا، فما عليك إلا تشغيل الأمر التالي:

npm install

إدارة الإصدارات وسرد إصدارات الحزم المثبتة

يدير npm أيضًا -بالإضافة إلى التنزيلات العادية- عملية الأصدَرة versioning، بحيث يمكنك تحديد إصدار معيّن من الحزمة، أو طلب إصدار أحدث أو أقدم مما تحتاجه، وستجد في كثير من الأحيان أنّ المكتبة متوافقة فقط مع إصدار رئيسي لمكتبة أخرى، أو قد تجد خطأً غير مُصحَّح بعد في الإصدار الأخير من مكتبة، مما يسبِّب مشاكلًا، كما يساعد تحديد إصدار صريح من مكتبة أيضًا في إبقاء كل فريق العمل على إصدار الحزمة الدقيق نفسه، بحيث يشغّل الفريق بأكمله الإصدار نفسه حتى تحديث ملف package.json.

تساعد عملية تحديد الإصدار كثيرًا في جميع الحالات السابقة، حيث يتبع npm معيار إدارة الإصدارات الدلالية semantic versioning - أو semver اختصارًا- والذي سنشرحه تاليًا في قسم منفصل، وقد تحتاج عمومًا إلى معرفة إصدار حزمة معينة ثبَّتها في تطبيقك، وهنا يمكنك استخدم الأمر التالي لمعرفة الإصدار الأحدث من جميع حزم npm المثبَّتة بالإضافة إلى اعتمادياتها:

npm list

إليك المثال التالي:

npm list

/Users/flavio/dev/node/cowsay
└─┬ cowsay@1.3.1
  ├── get-stdin@5.0.1
  ├─┬ optimist@0.6.1
  │ ├── minimist@0.0.10
  │ └── wordwrap@0.0.3
  ├─┬ string-width@2.1.1
  │ ├── is-fullwidth-code-point@2.0.0
  │ └─┬ strip-ansi@4.0.0
  │ └── ansi-regex@3.0.0
  └── strip-eof@1.0.0

يمكنك فتح ملف package-lock.json فقط، ولكنه يحتاج بعض الفحص البصري، حيث يطبق الأمر npm list -g الشيء نفسه ولكن للحزم المثبَّتة تثبيتًا عامًا، كما يمكنك الحصول على حزم المستوى الأعلى فقط، أي الحزم التي طلبتَ من npm تثبيتها وأدرجتَها في ملف package.json، من خلال تشغيل الأمر npm list --depth=0 كما يلي:

npm list --depth=0

/Users/flavio/dev/node/cowsay
└── cowsay@1.3.1

يمكنك الحصول على إصدار حزمة معينة عن طريق تحديد اسمها كما يلي:

npm list cowsay

/Users/flavio/dev/node/cowsay
└── cowsay@1.3.1

وتعمل هذه الطريقة أيضًا مع اعتماديات الحزم التي ثبَّتها كما يلي:

npm list minimist

/Users/flavio/dev/node/cowsay
└─┬ cowsay@1.3.1
  └─┬ optimist@0.6.1
     └── minimist@0.0.10

إذا أردت معرفة أحدث إصدار متوفر من الحزمة في مستودع npm، فشغّل الأمر npm view [package_name] version كما يلي:

npm view cowsay version

1.3.1

إلغاء تثبيت حزم npm

قد تسأل نفسك ماذا لو أردت إلغاء تثبيت حزمة npm المُثبَّتة تثبيتًا محليًا أو عامًا؟ يمكنك إلغاء تثبيت حزمة مثبَّتة مسبقًا محليًا locally باستخدام الأمر npm install <packagename>‎ في مجلد node_modules من خلال تشغيل الأمر التالي في مجلد جذر المشروع، أي المجلد الذي يحتوي على مجلد node_modules:

npm uninstall <package-name>

تُستخدَم الراية ‎-S أو ‎--save لإزالة جميع المراجع في ملف package.json، فإذا كانت الحزمة عبارة عن اعتمادية تطوير مُدرَجة في اعتماديات devDependencies الخاصة بملف package.json، فيجب عليك استخدام الراية ‎-D أو الراية ‎--save-dev لإزالتها من الملف كما يلي:

npm uninstall -S <package-name>
npm uninstall -D <package-name>

إذا ثُبِّتت الحزمة تثبيتًا عامًا globally، فيجب إضافة الراية ‎-g أو الراية ‎--global كما يلي:

npm uninstall -g <package-name>

إليك المثال التالي:

npm uninstall -g webpack

كما يمكنك تشغيل هذا الأمر من أي مكان تريده على نظامك لأن المجلد الذي تتواجد فيه حاليًا غير مهم.

تشغيل مهام وتنفيذ سكربتات من سطر الأوامر

يدعم ملف package.json تنسيقًا لتحديد مهام سطر الأوامر التي يمكن تشغيلها باستخدام الأمر التالي:

npm run <task-name>

فمثلًا:

{
  "scripts": {
     "start-dev": "node lib/server-development",
     "start": "node lib/server-production"
  },
}

يشيع استخدام هذه الميزة لتشغيل Webpack:

{
  "scripts": {
     "watch": "webpack --watch --progress --colors --config webpack.conf.js",
     "dev": "webpack --progress --colors --config webpack.conf.js",
     "prod": "NODE_ENV=production webpack -p --config webpack.conf.js",
  },
}

يمكنك تشغيل الأوامر التالية بدلًا من كتابة الأوامر الطويلة السابقة التي يسهل نسيانها أو كتابتها بصورة خاطئة:

$ npm run watch
$ npm run dev
$ npm run prod

الملف package.json نقطة ارتكاز المشروع

يُعَدّ ملف package.json عنصرًا أساسيًا في كثير من قواعد شيفرات التطبيقات المستندة إلى نظام Node.js المجتمعي، فإذا استخدمت سابقًا لغة جافاسكريبت أو تعاملت مع مشروع JavaScript أو Node.js أو مشروع واجهة أمامية، فلا بد أنك صادفت ملف package.json، كما يُعَدّ ملف package.json بيانًا manifest لمشروعك، إذ يمكنه تطبيق أشياء غير مرتبطة متعددة، فهو مستودع مركزي لإعداد الأدوات مثلًا، كما أنه المكان الذي يخزّن فيه npm وyarn أسماء وإصدارات الحزم المُثبَّتة.

معمارية الملف package.json

فيما يلي مثال لملف package.json:

{

}

هذا الملف فارغ، إذ لا توجد متطلبات ثابتة لما يجب تواجده في ملف package.json خاص بتطبيقٍ ما، فالشرط الوحيد هو أنه يجب أن يتبع تنسيق JSON، وإلّا فلا يمكن أن تقرأه البرامج التي تحاول الوصول إلى خصائصه برمجيًا، وإذا أردت بناء حزمة Node.js التي ترغب في توزيعها عبر npm، فسيتغيّر كل شيء جذريًا، إذ يجب أن يكون لديك مجموعة من الخصائص التي ستساعد الأشخاص الآخرين على استخدام هذا الملف، حيث سنتحدّث عن ذلك لاحقًا، وإليك مثال آخر عن ملف package.json:

{
  "name": "test-project"
}

يعرِّف الملف السابق خاصية الاسم name والتي تعطي اسم التطبيق أو الحزمة الموجودة في المجلد نفسه الذي يوجد فيه هذا الملف، وإليك المثال التالي الأكثر تعقيدًا والمُستخرَج من عينة تطبيق Vue.js:

{
  "name": "test-project",
  "version": "1.0.0",
  "description": "A Vue.js project",
  "main": "src/main.js",
  "private": true,
  "scripts": {
     "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
     "start": "npm run dev",
     "unit": "jest --config test/unit/jest.conf.js --coverage",
     "test": "npm run unit",
     "lint": "eslint --ext .js,.vue src test/unit",
     "build": "node build/build.js"
  },
  "dependencies": {
     "vue": "^2.5.2"
  },
  "devDependencies": {
     "autoprefixer": "^7.1.2",
     "babel-core": "^6.22.1",
     "babel-eslint": "^8.2.1",
     "babel-helper-vue-jsx-merge-props": "^2.0.3",
     "babel-jest": "^21.0.2",
     "babel-loader": "^7.1.1",
     "babel-plugin-dynamic-import-node": "^1.2.0",
     "babel-plugin-syntax-jsx": "^6.18.0",
     "babel-plugin-transform-es2015-modules-commonjs": "^6.26.0",
     "babel-plugin-transform-runtime": "^6.22.0",
     "babel-plugin-transform-vue-jsx": "^3.5.0",
     "babel-preset-env": "^1.3.2",
     "babel-preset-stage-2": "^6.22.0",
     "chalk": "^2.0.1",
     "copy-webpack-plugin": "^4.0.1",
     "css-loader": "^0.28.0",
     "eslint": "^4.15.0",
     "eslint-config-airbnb-base": "^11.3.0",
     "eslint-friendly-formatter": "^3.0.0",
     "eslint-import-resolver-webpack": "^0.8.3",
     "eslint-loader": "^1.7.1",
     "eslint-plugin-import": "^2.7.0",
     "eslint-plugin-vue": "^4.0.0",
     "extract-text-webpack-plugin": "^3.0.0",
     "file-loader": "^1.1.4",
     "friendly-errors-webpack-plugin": "^1.6.1",
     "html-webpack-plugin": "^2.30.1",
     "jest": "^22.0.4",
     "jest-serializer-vue": "^0.3.0",
     "node-notifier": "^5.1.2",
     "optimize-css-assets-webpack-plugin": "^3.2.0",
     "ora": "^1.2.0",
     "portfinder": "^1.0.13",
     "postcss-import": "^11.0.0",
     "postcss-loader": "^2.0.8",
     "postcss-url": "^7.2.1",
     "rimraf": "^2.6.0",
     "semver": "^5.3.0",
     "shelljs": "^0.7.6",
     "uglifyjs-webpack-plugin": "^1.1.1",
     "url-loader": "^0.5.8",
     "vue-jest": "^1.0.2",
     "vue-loader": "^13.3.0",
     "vue-style-loader": "^3.0.1",
     "vue-template-compiler": "^2.5.2",
     "webpack": "^3.6.0",
     "webpack-bundle-analyzer": "^2.9.0",
     "webpack-dev-server": "^2.9.1",
     "webpack-merge": "^4.1.0"
  },
  "engines": {
     "node": ">= 6.0.0",
     "npm": ">= 3.0.0"
  },
  "browserslist": [
     "> 1%",
     "last 2 versions",
     "not ie <= 8"
  ]
}

هناك خاصيات متعددة يجب شرحها في المثال السابق:

• name التي تضبط اسم التطبيق أو الحزمة.
• version التي تشير إلى الإصدار الحالي.
• description وهي وصف مختصَر للتطبيق أو للحزمة.
• main التي تضبط نقطة الدخول للتطبيق.
• private التي تمنع نشر التطبيق أو الحزمة عن طريق الخطأ على npm إذا ضُبِطت على القيمة true.
• scripts التي تحدّد مجموعة من سكربتات نود التي يمكنك تشغيلها.
• dependencies التي تضبط قائمة بحزم npm المثبَّتة كاعتماديات.
• devDependencies التي تضبط قائمة بحزم npm المثبَّتة كاعتماديات تطوير.
• engines التي تحدّد إصدار نود الذي تعمل عليه هذه الحزمة أو التطبيق.
• browserslist التي تُستخدَم لمعرفة المتصفحات وإصداراتها التي تريد دعمها.

تُستخدَم جميع هذه الخصائص إما باستخدام npm أو باستخدام أدوات أخرى.

خاصيات الملف package.json

يشرح هذا القسم الخاصيات التي يمكنك استخدامها ضمن الملف package.json بالتفصيل، حيث سنطبّق كل شيء على الحزمة، ولكن يمكن تطبيق الشيء نفسه على التطبيقات المحلية التي لا تستخدِمها على أساس حزم، كما تُستخدَم معظم هذه الخاصيات فقط على npm، ويُستخدَم البعض الآخر بواسطة السكربتات التي تتفاعل مع شيفرتك مثل npm أو غيره.

name

تضبط هذه الخاصية اسم الحزمة مثل المثال التالي:

"name": "test-project"

يجب أن يتضمّن الاسم أقل من 214 محرفًا وألا يحتوي على مسافات، كما لا يمكن أن يحتوي إلّا على أحرف صغيرة أو واصلات - أو شرطات سفلية _، وذلك لأن الحزمة تحصل على عنوان URL الخاص بها بناءً على هذه الخاصية عند نشرها على npm، إذا نشرتَ هذه الحزمة علنًا على GitHub، فستكون القيمة المناسبة لهذه الخاصية هي اسم مستودع GitHub.

author

تعطي هذه الخاصية اسم مؤلف الحزمة مثل المثال التالي:

{
  "author": "Flavio Copes <flavio@flaviocopes.com> (https://flaviocopes.com)"
}

يمكن استخدامها أيضًا بالتنسيق التالي:

{
  "author": {
     "name": "Flavio Copes",
     "email": "flavio@flaviocopes.com",
     "url": "https://flaviocopes.com"
  }
}

contributors

يمكن أن يكون للمشروع مساهم أو أكثر بالإضافة إلى المؤلف، وهذه الخاصية هي مصفوفة تعطي قائمة المساهمين مثل المثال التالي:

{
  "contributors": [
     "Flavio Copes <flavio@flaviocopes.com> (https://flaviocopes.com)"
  ]
}

كما يمكن استخدام هذه الخاصية أيضًا بالتنسيق التالي:

{
  "contributors": [
     {
        "name": "Flavio Copes",
        "email": "flavio@flaviocopes.com",
        "url": "https://flaviocopes.com"
     }
  ]
}

bugs

تُستخدَم هذه الخاصية للربط بمتتبّع مشاكل الحزمة، أي بصفحة مشاكل GitHub مثلًا كما يلي:

{
  "bugs": "https://github.com/flaviocopes/package/issues"
}

homepage

تضبط هذه الخاصية صفحة الحزمة الرئيسية مثل المثال التالي:

{
  "homepage": "https://flaviocopes.com/package"
}

version

تشير هذه الخاصية إلى إصدار الحزمة الحالي مثل المثال التالي:

"version": "1.0.0"

تتبع هذه الخاصية صيغة إدارة الإصدارات الدلالية semver، مما يعني أنّ الإصدار يُعبَّر عنه دائمًا بثلاثة أعداد: x.x.x، حيث يمثِّل العدد الأول الإصدار الرئيسي، ويمثِّل العدد الثاني الإصدار الثانوي؛ أما العدد الثالث فهو إصدار حزمة التصحيح patch version، فالإصدار الذي يصلح الأخطاء فقط هو إصدار حزمة التصحيح، والإصدار الذي يقدّم تغييرات متوافقة مع الإصدارات السابقة هو الإصدار الثانوي، كما يمكن أن يحتوي الإصدار الرئيسي على تغييرات جذرية.

license

تشير إلى رخصة الحزمة مثل المثال التالي:

"license": "MIT"

keywords

تحتوي هذه الخاصية على مصفوفة من الكلمات المفتاحية المرتبطة بما تفعله حزمتك مثل المثال التالي:

"keywords": [
  "email",
  "machine learning",
  "ai"
]

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

description

تحتوي هذه الخاصية على وصف مختصَر للحزمة مثل المثال التالي:

"description": "A package to work with strings"

هذه الخاصية مفيدة إذا قرّرت نشر حزمتك على npm لمعرفة معلومات الحزمة.

repository

تحدّد هذه الخاصية مكان وجود مستودع الحزمة مثل المثال التالي:

"repository": "github:flaviocopes/testing",

لاحظ البادئة github، وهناك خدمات شائعة أخرى مثل gitlab:

"repository": "gitlab:flaviocopes/testing",

وأيضًا bitbucket:

"repository": "bitbucket:flaviocopes/testing",

يمكنك ضبط نظام التحكم بالإصدارات بصورة صريحة كما يلي:

"repository": {
  "type": "git",
  "url": "https://github.com/flaviocopes/testing.git"
}

كما يمكنك استخدام أنظمة مختلفة للتحكم بالإصدارات كما يلي:

"repository": {
  "type": "svn",
  "url": "..."
}

main

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

"main": "src/main.js"

private

إذا ضُبِطت هذه الخاصية على القيمة true، فستمنع نشر التطبيق أو الحزمة عن طريق الخطأ على npm كما يلي:

"private": true

scripts

تحدّد هذه الخاصية مجموعة سكربتات نود التي يمكنك تشغيلها مثل المثال التالي:

"scripts": {
  "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
  "start": "npm run dev",
  "unit": "jest --config test/unit/jest.conf.js --coverage",
  "test": "npm run unit",
  "lint": "eslint --ext .js,.vue src test/unit",
  "build": "node build/build.js"
}

تُعَدّ هذه السكربتات تطبيقات سطر الأوامر، حيث يمكنك تشغيلها عن طريق استدعاء الأمر npm run XXXX أو yarn XXXX، حيث XXXX هو اسم الأمر مثل npm run dev، كما يمكنك إعطاء الأمر أيّ اسم تريده، ويمكن للسكربتات فعل أيّ شيء تريده.

dependencies

تضبط هذه الخاصية قائمة حزم npm المثبَّتة على أساس اعتماديات. إذا ثبَّتَ حزمةً باستخدام npm أو yarn كما يلي:

npm install <PACKAGENAME>
yarn add <PACKAGENAME>

ستُدخَل تلك الحزمة في هذه القائمة تلقائيًا، وإليك المثال التالي:

"dependencies": {
  "vue": "^2.5.2"
}

devDependencies

تضبط هذه الخاصية قائمة حزم npm المثبَّتة على أساس اعتماديات تطوير، وهي تختلف عن الخاصية dependencies لأنها مُخصَّصة للتثبيت على آلة تطوير فقط، وليست ضرورية لتشغيل الشيفرة في عملية الإنتاج، فإذا ثبَّتَ حزمةً باستخدام npm أو yarn:

npm install --dev <PACKAGENAME>
yarn add --dev <PACKAGENAME>

فستُدخَل تلك الحزمة في هذه القائمة تلقائيًا، وإليك المثال التالي:

"devDependencies": {
  "autoprefixer": "^7.1.2",
  "babel-core": "^6.22.1"
}

engines

تضبط هذه الخاصية إصدارات Node.js والأوامر الأخرى التي تعمل عليها هذه الحزمة أو التطبيق مثل المثال التالي:

"engines": {
  "node": ">= 6.0.0",
  "npm": ">= 3.0.0",
  "yarn": "^0.13.0"
}

browserslist

تُستخدَم هذه الخاصية لمعرفة المتصفحات وإصداراتها التي تريد دعمها، وقد أشارت إليها أدوات Babel وAutoprefixer وأدوات أخرى أنها تُستخدَم لإضافة تعويض نقص دعم المتصفحات polyfills والنسخ الاحتياطية fallbacks اللازمة للمتصفحات التي تستهدفها، وإليك المثال التالي:

"browserslist": [
  "> 1%",
  "last 2 versions",
  "not ie <= 8"
]

يعني الإعداد السابق أنك تريد دعم آخر إصدارين رئيسيين من جميع المتصفحات باستخدام 1‎%‎ على الأقل -من إحصائيات موقع caniuse- باستثناء الإصدار IE8 والإصدارات الأقدم (اطلع على المزيد من موقع حزمة).

خصائص خاصة بالأوامر

يمكن أن يستضيف ملف package.json أيضًا إعدادًا خاصًا بالأوامر مثل Babel وESLint وغير ذلك، فلكل منها خاصية معينة مثل eslintConfig وbabel وغيرها، وهذه هي الخصائص الخاصة بالأوامر، كما يمكنك العثور على كيفية استخدامها في توثيق الأمر أو المشروع المرتبط بها.

إصدارات الحزم

رأيت في الوصف أعلاه أرقام الإصدارات مثل: ‎~3.0.0 أو ‎^0.13.0، حيث يحدِّد الرمز الموجود على يسار رقم الإصدار التحديثات التي تقبلها الحزمة من تلك الاعتمادية، ولنفترض استخدام semver -الأصدَرة الدلالية semantic versioning-، حيث تتضمن جميع الإصدارات 3 خانات عددية، أولها هو الإصدار الرئيسي وثانيها هو الإصدار الثانوي وثالثها هو إصدار حزمة التصحيح patch release، وبالتالي لديك القواعد التالية:

• ~: إذا كتبت ‎~0.13.0، فهذا يعني أنك تريد فقط تحديث إصدارات حزمة التصحيح، أي أنّ الإصدار 0.13.1 مقبول، ولكن الإصدار 0.14.0 ليس كذلك.
• ^: إذا كتبت ‎^0.13.0، فهذا يعني أنك تريد تحديث إصدار حزمة التصحيح والإصدار الثانوي، أي الإصدارات 0.13.1 و0.14.0 وهكذا.
• *: إذا كتبت *، فهذا يعني أنك تقبل جميع التحديثات بما في ذلك ترقيات الإصدارات الرئيسية.
• <: أي أنك تقبل أي إصدار أعلى من الإصدار الذي تحدِّده.
• =‎<: أي أنك تقبل أي إصدار مساوي أو أعلى من الإصدار الذي تحدِّده.
• =>: أي أنك تقبل أي إصدار مساوي أو أدنى من الإصدار الذي تحدِّده.
• >: أي أنك تقبل أي إصدار أدنى من الإصدار الذي تحدِّده.

وهناك قواعد أخرى هي:

• بدون رمز: أي أنك تقبل فقط الإصدار الذي تحدّده.
• latest: أي أنك تريد استخدام أحدث إصدار متاح.

كما يمكنك دمج معظم ما سبق ضمن مجالات مثل 1.0.0‎ || >=1.1.0 <1.2.0 لاستخدم إما الإصدار 1.0.0 أو أحد الإصدارات الأعلى أو المساوية للإصدار 1.1.0 والأدنى من الإصدار 1.2.0.

الملف package-lock.json ودوره في إدارة الإصدارات

يُنشَأ الملف package-lock.json تلقائيًا عند تثبيت حزم نود، حيث قدَّم npm ملف package-lock.json في الإصدار رقم 5، والهدف من هذا الملف هو تتبّع الإصدار الدقيق لكل حزمة مثبَّتة، وبالتالي فإن المنتج قابل لإعادة الإنتاج بنسبة 100% بالطريقة نفسها حتى إذا حدّث القائمون على الصيانة الحزم، كما يحل ذلك مشكلةً تركَها ملف package.json دون حل، إذ يمكنك في ملف package.json ضبط الإصدارات التي تريد الترقية إليها -أي إصدار حزمة التصحيح أو الإصدار الثانوي- باستخدام صيغة semver كما يلي:

• إذا كتبت ‎~0.13.0، فهذا يعني أنك تريد فقط تحديث إصدار حزمة التصحيح، أي أن الإصدار 0.13.1 مقبول، ولكن الإصدار 0.14.0 ليس كذلك.
• إذا كتبت ‎^0.13.0، فهذا يعني أنك تريد تحديث إصدار حزمة التصحيح والإصدار الثانوي، أي الإصدارات 0.13.1 و0.14.0 وهكذا.
• إذا كتبت 0.13.0، فهذا يعني الإصدار الدقيق الذي سيُستخدَم.

لستَ ملزَمًا بتوزيع مجلد node_modules الضخم باستخدام برنامج جت Git، وإذا حاولتَ نسخ المشروع على جهاز آخر باستخدام الأمر npm install -إذا حدّدتَ الصيغة ~ مع إصدار حزمة التصحيح الخاص بالحزمة- فسيثبَّت هذا الإصدار، كما يحدث الأمر ذاته مع الصيغة ^ والإصدارات الثانوية.

اقتباس

توضيح: إذا حدّدتَ إصدارات معينة مثل الإصدار 0.13.0، فلن تتأثر بهذه المشكلة.

قد تحاول أنت أو أي شخص آخر تهيئة المشروع على الجانب الآخر من العالم عن طريق تشغيل الأمر npm install، لذلك فإن مشروعك الأصلي والمشروع المُهيَّأ حديثًا مختلفان فعليًا، إذ يجب ألّا يدخِل إصدار حزمة التصحيح أو الإصدار الثانوي تغييرات معطِّلة، ولكننا نعلم أن الأخطاء ممكنة الحدوث وستحدث بالفعل.

يضبط ملف package-lock.json الإصدار المثبَّت حاليًا من كل حزمة باستخدام رمز stone، وسيستخدِم npm هذه الإصدارات المحدَّدة عند تشغيل الأمر npm install، كما أنّ هذا المفهوم ليس بجديد، إذ يستخدِم مديرو حزم لغات البرمجة الأخرى -مثل مكتبات Composer في لغة PHP- نظامًا مشابهًا منذ سنوات.

يجب أن يكون ملف package-lock.json ملتزمًا بمستودع Git الخاص بك حتى يجلبه أشخاص آخرون إذا كان المشروع عامًا أو لديك متعاونون أو إذا استخدمت Git على أساس مصدر لعمليات النشر، كما ستُحدَّث إصدارات الاعتماديات في ملف package-lock.json عند تشغيل الأمر npm update.

يوضِّح المثال التالي معمارية ملف package-lock.json التي نحصل عليها عند تشغيل الأمر npm install cowsay في مجلد فارغ:

{
  "requires": true,
  "lockfileVersion": 1,
  "dependencies": {
     "ansi-regex": {
        "version": "3.0.0",
        "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-3.0.0.tgz",
        "integrity": "sha1-7QMXwyIGT3lGbAKWa922Bas32Zg="
  },
  "cowsay": {
     "version": "1.3.1",
     "resolved": "https://registry.npmjs.org/cowsay/-/cowsay-1.3.1.tgz",
     "integrity": "sha512-3PVFe6FePVtPj1HTeLin9v8WyLl+VmM1l1H/5P+BTTDkMAjufp+0F9eLjzRnOHzVAYeIYFF5po5NjRrgefnRMQ==",
     "requires": {
        "get-stdin": "^5.0.1",
        "optimist": "~0.6.1",
        "string-width": "~2.1.1",
        "strip-eof": "^1.0.0"
     }
  },
  "get-stdin": {
     "version": "5.0.1",
     "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-5.0.1.tgz",
     "integrity": "sha1-Ei4WFZHiH/TFJTAwVpPyDmOTo5g="
  },
  "is-fullwidth-code-point": {
     "version": "2.0.0",
     "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-2.0.0.tgz",
     "integrity": "sha1-o7MKXE8ZkYMWeqq5O+764937ZU8="
  },
  "minimist": {
     "version": "0.0.10",
     "resolved": "https://registry.npmjs.org/minimist/-/minimist-0.0.10.tgz",
     "integrity": "sha1-3j+YVD2/lggr5IrRoMfNqDYwHc8="
  },
  "optimist": {
     "version": "0.6.1",
     "resolved": "https://registry.npmjs.org/optimist/-/optimist-0.6.1.tgz",
     "integrity": "sha1-2j6nRob6IaGaERwybpDrFaAZZoY=",

     "requires": {
        "minimist": "~0.0.1",
        "wordwrap": "~0.0.2"
     }
  },
  "string-width": {
     "version": "2.1.1",
     "resolved": "https://registry.npmjs.org/string-width/-/string-width-2.1.1.tgz",
     "integrity": "sha512-nOqH59deCq9SRHlxq1Aw85Jnt4w6KvLKqWVik6oA9ZklXLNIOlqg4F2yrT1MVaTjAqvVwdfeZ7w7aCvJD7ugkw==",
     "requires": {
        "is-fullwidth-code-point": "^2.0.0",
        "strip-ansi": "^4.0.0"
     }
  },
  "strip-ansi": {
     "version": "4.0.0",
     "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-4.0.0.tgz",
     "integrity": "sha1-qEeQIusaw2iocTibY1JixQXuNo8=",
     "requires": {
        "ansi-regex": "^3.0.0"
     }
  },
  "strip-eof": {
     "version": "1.0.0",
     "resolved": "https://registry.npmjs.org/strip-eof/-/strip-eof-1.0.0.tgz",
     "integrity": "sha1-u0P/VZim6wXYm1n80SnJgzE2Br8="
  },
  "wordwrap": {
     "version": "0.0.3",
     "resolved": "https://registry.npmjs.org/wordwrap/-/wordwrap-0.0.3.tgz",
     "integrity": "sha1-o9XabNXAvAAI03I0u68b7WMFkQc="
     }
  }
}

ثبّتنا حزمة cowsay التي تعتمد على الحزم التالية:

• get-stdin.
• optimist.
• string-width.
• strip-eof.

تتطلب هذه الحزم حزمًا أخرى مثل الحزم الموجودة في الخاصية requires كما يلي:

• ansi-regex.
• is-fullwidth-code-point.
• minimist.
• wordwrap.
• strip-eof.

تُضاف هذه الحزم إلى الملف بالترتيب الأبجدي، ولكل منها حقل version، وحقل resolved يؤشّر إلى موقع الحزمة، وسلسلة نصية integrity يمكننا استخدامها للتحقق من الحزمة.

قواعد الإدارة الدلالية لنسخ الاعتماديات

تُعَدّ الإدارة الدلالية لنسخ الاعتماديات Semantic Versioning اصطلاحًا يُستخدَم لتوفير معنى للإصدارات، فإذا كان هناك شيء رائع في حزم Node.js، فهو اتفاق الجميع على استخدام هذا المفهوم لترقيم إصداراتهم، كما يُعَدّ مفهوم الإدارة الدلالية للنسخ بسيطًا للغاية، فلكل الإصدارات 3 خانات عددية x.y.z:

• العدد الأول هو الإصدار الرئيسي.
• العدد الثاني هو الإصدار الثانوي.
• العدد الثالث هو إصدار التصحيح.

إذا أردت إنشاء إصدار جديد، فلن تزيد عددًا كما يحلو لك، بل لديك قواعد يجب الالتزام بها وهي:

• يُحدَّث الإصدار الرئيسي عند إجراء تغييرات غير متوافقة مع واجهة برمجة التطبيقات API.
• يُحدَّث الإصدار الثانوي عند إضافة عمليات بطريقة متوافقة مع الإصدارات السابقة.
• يُحدَّث إصدار تصحيح عند إجراء إصلاحات أخطاء متوافقة مع الإصدارات السابقة.

اُعتمِد هذا المفهوم في جميع لغات البرمجة ومن المهم أن تلتزم بها كل حزمة npm لأن النظام بأكمله يعتمد على ذلك، إذ وضَع npm بعض القواعد التي يمكننا استخدامها في ملف package.json لاختيار الإصدارات التي يمكن تحديث حزمنا إليها عند تشغيل الأمر npm update، وتستخدِم هذه القواعد الرموز التالية:

• ^: إذا كتبت ‎^0.13.0 عند تشغيل الأمر npm update، فهذا يؤدي إلى تحديث إصدار حزمة التصحيح والإصدار الثانوي، أي الإصدارات 0.13.1 و0.14.0 وهكذا.
• ~: إذا كتبت ‎~0.13.0 عند تشغيل الأمر npm update، فهذا يؤدي إلى تحديث إصدارات حزمة التصحيح، أي أن الإصدار 0.13.1 مقبول، ولكن الإصدار 0.14.0 ليس كذلك.
• <: أي أنك تقبل أي إصدار أعلى من الإصدار الذي تحدده.
• =‎<: أي أنك تقبل أي إصدار مساوي أو أعلى من الإصدار الذي تحدّده.
• =>: أي أنك تقبل أي إصدار مساوي أو أدنى من الإصدار الذي تحدّده.
• >: أي أنك تقبل أي إصدار أدنى من الإصدار الذي تحدّده.
• =: أي أنك تقبل الإصدار المحدَّد.
• -: أي أنك تقبل مجالًا من الإصدارات مثل المجال مثل: 2.1.0‎ - 2.6.2.
• ||: يُستخدَم لدمج مجموعات من الإصدارات مثل: ‎< 2.1 || > 2.6.

يمكنك دمج بعض القواعد السابقة مثل: 1.0.0‎ || >=1.1.0 <1.2.0 لاستخدام إما الإصدار 1.0.0 أو أحد الإصدارات الأعلى أو المساوية للإصدار 1.1.0 والأدنى من الإصدار 1.2.0.

هناك قواعد أخرى أيضًا هي:

• بدون رمز: أي أنك تقبل فقط الإصدار الذي تحدّده مثل: 1.2.1.
• latest: أي أنك تريد استخدام أحدث إصدار متاح.

أنواع الحزم

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

الحزم العامة والحزم المحلية

الفرق الرئيسي بين الحزم المحلية والعامة هو:

• تُثبَّت الحزم المحلية في المجلد أو المسار حيث تشغّل الأمر npm install <package-name>‎، وتوضَع في مجلد node_modules ضمن هذا المجلد أو المسار.
• توضَع جميع الحزم العامة في مكان واحد في نظامك بالاعتماد على إعدادك الخاص بغض النظر عن مكان تشغيل الأمر npm install -g <package-name>‎.

وكلاهما مطلوب بالطريقة نفسها في شيفرتك الخاصة كما يلي:

require('package-name')

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

تحتوي جميع المشاريع على نسختها المحلية الخاصة من الحزمة، فقد يبدو ذلك ضياعًا للموارد، ولكنه ضياع ضئيل بالموازنة مع العواقب السلبية المحتمَلة، كما يجب تثبيت الحزمة العامة عندما توفِّر هذه الحزمة أمرًا قابلًا للتنفيذ بحيث تشغّله من الصدفة shell أي واجهة سطر الأوامر CLI، ويُعاد استخدام هذه الحزمة عبر المشاريع، كما يمكنك أيضًا تثبيت الأوامر القابلة للتنفيذ محليًا وتشغيلها باستخدام npx، ولكن تثبيت الحزم العامة أفضل بالنسبة لبعض الحزم.

فيما يلي أمثلة رائعة عن الحزم العامة الشائعة التي قد تعرفها:

• npm.
• create-react-app.
• vue-cli.
• grunt-cli.
• mocha.
• react-native-cli.
• gatsby-cli.
• forever.
• nodemon.

يُحتمَل أن تكون لديك بعض الحزم العامة المثبَّتة على نظامك التي يمكنك رؤيتها عن طريق تشغيل الأمر التالي في سطر الأوامر الخاص بك:

npm list -g --depth 0

الاعتماديات الأساسية واعتماديات التطوير

إذا ثبَّتَ حزمة npm باستخدام الأمر npm install <package-name>‎، فهذا يعني أنك ثبّتها على أساس اعتمادية dependency، حيث تُدرَج الحزمة تلقائيًا في ملف package.json ضمن قائمة dependencies بدءًا من الإصدار npm 5، إذ احتجنا سابقًا إلى تحديد الراية ‎--save يدويًا، فإذا أضفتَ الراية ‎-D أو الراية ‎--save-dev، فهذا يعني أنك تثبّتها على أساس اعتمادية تطوير، وبالتالي ستُضاف إلى قائمة devDependencies.

يُقصَد باعتماديات التطوير أنها حزم للتطوير فقط، وهي غير ضرورية في عملية الإنتاج مثل حزم الاختبار أو حزم webpack أو Babel، فإذا كتبت الأمر npm install واحتوى المجلد على ملف package.json في عملية الإنتاج، فستُثبَّت اعتماديات التطوير، حيث يفترض npm أنّ هذه عملية نشر تطوير، كما يجب ضبط الراية ‎--production من خلال الأمر npm install --production لتجنب تثبيت اعتماديات التطوير.

npx

يُعَدّ npx طريقةً رائعةً جدًا لتشغيل شيفرة نود، كما يوفِّر ميزات مفيدةً متعددةً، إذ كان متاحًا في npm بدءًا من الإصدار 5.2، الذي صدر في شهر 7 من عام 2017.

اقتباس

توضيح: إذا لم ترغب في تثبيت npm، فيمكنك تثبيت npx على أساس حزمة قائمة بذاتها.

يتيح لك npx تشغيل الشيفرة المُنشَأة باستخدام نود والمنشورة من خلال سجل npm، كما يتميز npx بالميزات التالية:

تشغيل الأوامر المحلية بسهولة

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

تنفيذ الأوامر دون تثبيتها

هناك ميزة أخرى رائعة في npm تسمح بتشغيل الأوامر دون تثبيتها أولًا، حيث يُعَدّ ذلك مفيدًا جدًا للأسباب التالية:

1. لا تحتاج إلى تثبيت أي شيء.
2. يمكنك تشغيل إصدارات مختلفة من الأمر نفسه باستخدام صيغة ‎.@version

يمكن توضيح استخدام npx من خلال الأمر cowsay الذي سيطبع بقرةً تقول ما تكتبه ضمن الأمر، حيث سيطبع الأمر cowsay "Hello"‎ ما يلي على سبيل المثال:

_______
< Hello >
-------
        \ ^__^
        \ (oo)\_______
          (__)\       )\/\
              ||----w |
              ||     ||

يحدث ذلك إذا كان الأمر cowsay مثبَّتًا تثبيتًا عامًا من npm سابقًا، وإلا فستحصل على خطأ عند محاولة تشغيل الأمر، كما يسمح لك npx بتشغيل الأمر npm السابق دون تثبيته محليًا كما يلي:

npx cowsay "Hello"

يُعَدّ الأمر السابق للتسلية فقط ودون فائدة، ولكن يمكنك استخدام npx في حالات مهمة أخرى مثل:

• تشغيل أداة واجهة سطر الأوامر vue لإنشاء تطبيقات جديدة وتشغيلها باستخدام الأمر npx vue create myvue-app
• إنشاء تطبيق React جديد باستخدام الأمر npx create-react-app my-react-app.

و حالات أخرى أيضًا، كما ستُمسَح الشيفرة المُنزَّلة لهذه الأوامر بمجرد تنزيلها.

تشغيل شيفرة باستخدام إصدار نود Node مختلف

استخدم الرمز @ لتحديد الإصدار، وادمج ذلك مع حزمة npm التي هي node:

npx node@6 -v #v6.14.3
npx node@8 -v #v8.11.3

يساعد ذلك في تجنب استخدام أدوات مثل أداة nvm أو أدوات إدارة إصدارات نود الأخرى.

تشغيل أجزاء شيفرة عشوائية مباشرة من عنوان URL

لا يقيّدك npx بالحزم المنشورة في سجل npm، إذ يمكنك تشغيل الشيفرة الموجودة في GitHub gist مثل المثال التالي:

npx https://gist.github.com/zkat/4bc19503fe9e9309e2bfaa2c58074d32

يجب أن تكون حذرًا عند تشغيل شيفرة لا تتحكم بها، فالقوة العظمى تستوجب مسؤولية عظمى أيضًا.

ترجمة -وبتصرّف- للفصل Node modules and npm من كتاب The Node.js handbook لصاحبه Flavio Copes.

اقرأ أيضًا

• المقال التالي: كيفية تنفيذ الدوال داخليا ضمن Node.js
• المقال السابق: استخدام الوضع التفاعلي والتعامل مع سطر الأوامر في Node.js
• مقدمة إلى Node.js
• تأمين تطبيق Node.js يعمل على الحاويات باستخدام Nginx و Let’s Encrypt و Compose Docker

سنتعرّف في هذا المقال على الوضع التفاعلي REPL في Node.js الذي نستخدمه في الطرفية لتقييم تعبير برمجي مكتوب بلغة javascript، كما سنتعلّم كيفية التعامل مع سطر الأوامر في Node.js من تمرير وسائط منه وإرسال مخرجات إليه وقبول مدخلات منه.

استخدام الوضع التفاعلي REPL

يسمى الوضع التفاعلي في Node.js باسم REPL اختصارًا إلى اقرأ-قيّم-اطبع-كرر Read-Evaluate-Print-Loop، أي اقرأ وقدِّر قيمة التعبير البرمجي ثم اطبع الناتج وكرر العملية، وهو طريقة رائعة لاستكشاف ميزات Node.js بطريقة سريعة.

استعملنا الأمر node سابقًا لتشغيل أحد السكربتات:

node script.js

أما إذا حذفنا اسم الملف، فسندخل في الوضع التفاعلي REPL:

node

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

$ node
Welcome to Node.js v14.15.0.
Type ".help" for more information.
> 

اقتباس

ملاحظة: إذا لم تكن تعرف كيف تفتح الطرفية عندك، فيمكنك البحث في جوجل عن ذلك مع ذكر نظام التشغيل الخاص بك، وانظر مقال "مدخل إلى طرفيّة لينكس".

إذا أردنا أن نكون أكثر دقةً، فإن الوضع التفاعلي ينتظر منّا إدخال شيفرة JavaScript، لذا لنبدأ بسطر بسيط:

> console.log('test')
test
undefined
>

القيمة الأولى المطبوعة test هي ناتج الأمر الذي طلبنا منه طباعة سلسلة نصية إلى الطرفية، ثم حصلنا على القيمة undefined وهي القيمة المعادة من تنفيذ console.log()‎، ويمكننا الآن إدخال سطر JavaScript جديد.

استخدام الزر tab للإكمال التلقائي

من أجمل مزايا الوضع التفاعلي REPL هو أنه تفاعلي، ففي أثناء كتابك للشيفرة إذا ضغطت على زر tab، فسيحاول الوضع التفاعلي الإكمال التلقائي لما كتبته ليوافق اسم متغير عرفته مسبقًا.

استكشاف كائنات JavaScript

جرِّب إدخال اسم كائن من كائنات JavaScript مثل Number وأضف إليه نقطةً ثم اضغط على tab، إذ سيعرض لك الوضع التفاعلي جميع الخاصيات والتوابع التي يمكنك الوصول إليها في ذاك الكائن.

استكشاف الكائنات العامة

يمكنك معاينة الكائنات العامة بكتابة global.‎ ثم الضغط على الزر tab:

المتغير الخاص _

إذا كتبت _ بعد شيفرة ما، فسيؤدي ذلك إلى طباعة ناتج آخر عملية.

الأوامر ذوات النقط

يملك الوضع التفاعلي REPL بعض الأوامر الخاصة وكلها تبدأ بنقطة . وهي:

• ‎.help: يظهر المساعدة للأوامر ذوات النقط.
• ‎.editor: تفعيل وضع المحرر، وذلك لكتابة شيفرة JavaScript متعددة الأسطر بسهولة، وبعد دخولك في هذا الوضع وكتابتك للشيفرة المطلوبة، فيمكنك إدخال Ctrl+D لتنفيذ الأمر الذي كتبت.
• ‎.break: إذا كتبت الأمر ‎.break عند كتابتك لتعبير متعدد الأسطر، فستلغي أي مدخلات قادمة، ومثله مثل الضغط على Ctrl+C.
• ‎.clear: إعادة ضبط سياق الوضع التفاعلي إلى كائن فارغ وإزالة أي تعابير متعددة الأسطر جرت كتابتها.
• ‎.load: تحميل ملف JavaScript بمسار نسبي إلى مجلد العمل الحالي.
• ‎.save: حفظ ما أدخلته في الجلسة التفاعلية إلى ملف مع تمرير مسار الملف بعد كتابة ‎.save.
• ‎‎.exit: الخروج من الوضع التفاعلي وهو يماثل الضغط على Ctrl+C مرتين.

يعرِف الوضع التفاعلي REPL متى تكتب تعبيرًا متعدد الأسطر دون الحاجة إلى تشغيل الأمر ‎.editor، فإذا بدأت مثلًا بكتابة حلقة تكرار مثل هذه:

[1, 2, 3].forEach(num => {

ثم ضغطت على زر enter، فسيعرف الوضع التفاعلي أنك تكتب تعبيرًا متعدد الأسطر ويبدأ سطرًا جديدًا بثلاث نقط …، مما يشير إلى أنك ما زلت تعمل على القسم أو المقطع نفسه:

... console.log(num)
... })

إذا كتبت ‎.break في آخر السطر، فسيتوقف وضع تعدد الأسطر ولن يُنفَّذ التعبير الذي كتبته.

تمرير الوسائط من سطر الأوامر إلى Node.js

سنشرح في هذا القسم كيفية استقبال وسائط arguments في برنامج Node.js مُمرَّرة من سطر الأوامر، إذ يمكنك تمرير أي عدد من الوسائط أثناء تشغيل برنامج Node.js باستخدام الأمر:

node app.js

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

node app.js ahmed

أو

node app.js name=ahmed

يجعل هذا طريقة الحصول على القيمة مختلفةً في شيفرة Node.js. إذ أنّ طريقة الحصول على الوسائط هي استخدام الكائن process المبني في Node.js، ففيه الخاصية argv التي هي مصفوفة تحتوي على جميع الوسائط الممررة عبر سطر الأوامر؛ ويكون الوسيط الأول هو المسار الكامل للأمر node، بينما الوسيط الثاني هو مسار الملف المُنفَّذ كاملًا، وجميع الوسائط الإضافية ستكون موجودةً من الموضع الثالث إلى آخره، كما يمكنك المرور على جميع المعاملات بما في ذلك مسار node ومسار الملف المُنفَّذ باستخدام حلقة تكرار:

process.argv.forEach((val, index) => {
  console.log(`${index}: ${val}`)
})

يمكنك الحصول على الوسائط الإضافية من خلال إنشاء مصفوفة جديدة تستثني أول قيمتين:

const args = process.argv.slice(2)

إذا كان لديك معامل بمفرده دون مفتاح مثل:

node app.js ahmed

فيمكنك الوصول إليه كما يلي:

const args = process.argv.slice(2)
args[0]

أما في حالة كان الوسيط هو مفتاح وقيمة كما في:

node app.js name=ahmed

فإن قيمة args[0]‎ هي name=ahmed، وستحتاج إلى تفسيرها، وأفضل طريقة هي استخدام المكتبة minimist التي تساعدنا بالتعامل مع الوسائط:

const args = require('minimist')(process.argv.slice(2))
args['name'] // ahmed

إرسال تطبيق Node.js المخرجات إلى سطر الأوامر

سنتعلم كيفية الطباعة إلى سطر الأوامر باستخدام Node.js بدءًا من الاستخدام الأساسي للتابع console.log حتى وصولنا إلى الأمور المعقدة.

طباعة المخرجات باستخدام الوحدة console

توفِّر Node.js الوحدة console التي توفر عددًا كبيرًا من الطرائق المفيدة في التعامل مع سطر الأوامر، وهي تشبه إلى حد ما الكائن console الموجود في المتصفحات، والتابع الأساسي الأكثر استخدامًا في هذه الوحدة هو التابع console.log()‎، الذي يطبع السلسلة النصية التي تمررها إليه إلى الطرفية، وإذا مررت كائنًا فسيعرضه على أساس سلسلة نصية، كما يمكنك تمرير قيمًا متعددةً إلى التابع console.log()‎ كما يلي، إذ ستطبع Node.js القيمتين x وy معًا:

const x = 'x'
const y = 'y'
console.log(x, y)

يمكنك أيضًا تنسيق السلاسل النصية بتمرير القيم ومُحدِّد التنسيق كما في المثال التالي:

console.log('My %s has %d years', 'cat', 2)

إذ أنّ محددات التنسيق format specifiers هي:

• ‎%s: تنسيق المتغير على أساس سلسلة نصية.
• ‎%d أو ‎%i: تنسيق المتغير على أساس عدد صحيح.
• ‎%f: تنسيق المتغير على أساس عدد ذي فاصلة عشرية.
• ‎%O: تنسيق المتغير على أساس كائن كما في المثال البسيط الآتي:

console.log('%O', Number)

مسح محتوى الطرفية

يمسح التابع console.clear()‎ محتوى الطرفية، لكن يختلف سلوكه اعتمادًا على الطرفية المستخدَمة.

عد العناصر

يُعَدّ التابع console.count()‎ مفيدًا في بعض الحالات التي تريد فيها عدّ المرات التي طُبِعَت فيها السلسلة النصية وإظهار الرقم بجوارها، خذ هذا المثال:

const x = 1
const y = 2
const z = 3
console.count(
  'The value of x is ' + x + ' and has been checked .. how many times?'
)
console.count(
  'The value of x is ' + x + ' and has been checked .. how many times?'
)
console.count(
  'The value of y is ' + z + ' and has been checked .. how many times?'
)

يمكننا إحصاء عدد البرتقالات والتفاحات التي لدينا:

const oranges = ['orange', 'orange']
const apples = ['just one apple']
oranges.forEach(fruit => {
  console.count(fruit)
})
apples.forEach(fruit => {
  console.count(fruit)
})

طباعة تتبع مكدس الاستدعاء

قد تكون هنالك حالات من المفيد فيها طباعة تتبع مكدس الاستدعاء call stack trace لإحدى الدوال، وذلك للإجابة مثلًا على السؤال التالي: كيف وصلنا إلى هذا الجزء من الشيفرة، إذ يمكنك استخدام التابع console.trace()‎:

const function2 = () => console.trace()
const function1 = () => function2()
function1()

سيطبع مكدس الاستدعاء ما يلي، وهذا هو الناتج إذا جربنا الشيفرة السابقة في النمط التفاعلي REPL في Node.js:

Trace
    at function2 (repl:1:33)
    at function1 (repl:1:25)
    at repl:1:1
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at REPLServer.defaultEval (repl.js:239:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:440:10)
    at emitOne (events.js:120:20)
    at REPLServer.emit (events.js:210:7)

طباعة الزمن المستغرق

يمكنك ببساطة حساب مقدار الوقت الذي أخذته الدالة للتنفيذ باستخدام التابعين time()‎ وtimeEnd()‎ كما في المثال التالي:

const doSomething = () => console.log('test')
const measureDoingSomething = () => {
  console.time('doSomething()')
  // افعل شيئًا وقس الوقت المستغرق لتنفيذه
  doSomething()
  console.timeEnd('doSomething()')
}
measureDoingSomething()

مجرى الخرج القياسي stdout والخطأ القياسي stderr

رأينا أنّ التابع console.log()‎ رائع لطباعة الرسائل في الطرفية، وهذا ما يسمى مجرى الخرج القياسي standard output stream أو stdout؛ أما التابع console.error()‎ فسيطبع الرسائل المرسَلة إلى مجرى الخطأ القياسي stderr والتي لن تظهر في الطرفية وإنما ستظهر في سجل الخطأ.

طباعة المخرجات بألوان مختلفة

يمكنك أن تغيير لون المخرجات النصية في الطرفية باستخدام تسلسلات التهريب escape sequences، وتسلسل التهريب هو مجموعة من المحارف التي تُعرِّف لونًا معينًا في الطرفية مثل:

console.log('\x1b[33m%s\x1b[0m', 'hi!')

يمكنك تجربة ذلك باستخدام النمط التفاعلي في Node.js وستُعرَض السلسلة النصية hi!‎ باللون الأصفر، لكن هذه الطريقة ذات مستوى منخفض، فأبسط طريقة لتلوين المخرجات في الطرفية هي باستخدام مكتبة مثل Chalk، حيث يمكنها أيضًا إجراء عمليات التنسيق الأخرى إضافةً إلى تلوينها للنص مثل جعل النص غامقًا أو مائلًا أو مسطرًا تحته، كما يمكنك تثبيتها باستخدام npm install chalk ثم استخدامها:

const chalk = require('chalk')
console.log(chalk.yellow('hi!'))

من المؤكد أن استخدام chalk.yellow أكثر راحةً من محاولة تذكُّر شيفرات التهريب وستكون قابلية قراءة الشيفرة أفضل.

إنشاء شريط تقدم في الطرفية

تُعَدّ حزمة Progress حزمةً رائعةً لإنشاء شريط تقدُّم في الطرفية، حيث يمكنك تثبيتها باستخدام npm install progress ببساطة.

تُنشِئ الشيفرة التالية شريط تقدُّم بعشر خطوات، حيث ستكتمل خطوة كل 100 ميللي ثانية، وحين اكتمال الشريط سنصفِّر العداد:

const ProgressBar = require('progress')

const bar = new ProgressBar(':bar', { total: 10 })
const timer = setInterval(() => {
  bar.tick()
  if (bar.complete) {
    clearInterval(timer)
  }
}, 100)

قبول المدخلات من سطر الأوامر

يمكننا جعل تطبيق Node.js الذي يعمل من سطر الأوامر تفاعليًا باستخدام وحدة readline المبنية في أساس Node.js.

أصبحت Node.js بدءًا من الإصدار السابع توفِّر الوحدة readline التي تحصل على المدخلات من مجرى قابل للقراءة مثل process.stdin (مجرى الدخل القياسي stdin) سطرًا بسطر والذي يكون أثناء تنفيذ برنامج Node.js من سطر الأوامر هو الدخل المكتوب في الطرفية.

const readline = require('readline').createInterface({
  input: process.stdin,
  output: process.stdout
})


readline.question(`What's your name?`, (name) => {
  console.log(`Hi ${name}!`)
  readline.close()
})

تسأل الشيفرة السابقة المستخدِم عن اسمه، وبعد كتابة المستخدِم الاسم والضغط على enter سنرسل تحيةً له.

يُظهِر التابع question()‎ المعامل parameter الأول -أي السؤال- وينتظر مدخلات المستخدِم، ثم يستدعي دالة رد نداء عندما يضغط المستخدِم على زر enter. لاحظا أننا أغلقنا واجهة readline في دالة رد النداء، كما توفِّر الواجهة readline توابعًا كثيرةً متعددةً وسنتركك لاستكشافها من توثيقها؛ أما إذا احتجت إلى إدخال كلمة مرور، فمن الأفضل إظهار رمز * بدلًا منها، وأسهل طريقة لذلك هو استخدام الحزمة readline-sync التي تشبه readline في الواجهة البرمجية وتستطيع التعامل مع هذه الحالة دون عناء، والخيار الممتاز والمتكامل هو الحزمة inquirer.js، حيث يمكنك تثبيتها باستخدام npm install inquirer، كما يمكنك إعادة كتابة الشيفرة السابقة كما يلي:

const inquirer = require('inquirer')

var questions = [{
  type: 'input',
  name: 'name',
  message: "What's your name?",
}]

inquirer.prompt(questions).then(answers => {
  console.log(`Hi ${answers['name']}!`)
})

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

ترجمة -وبتصرّف- للفصل Command Line من كتاب The Node.js handbook لصاحبه Flavio Copes.

اقرأ أيضًا

• المقال التالي: دليلك الشامل إلى مدير الحزم npm في Node.js
• المقال السابق: مقدمة إلى Node.js
• تأمين تطبيق Node.js يعمل على الحاويات باستخدام Nginx و Let’s Encrypt و Compose Docker
• نشر تطبيق Node.js على الويب: خدمة هيروكو (Heroku) مثالًا

تُعَدّ Node.js بيئة تشغيل JavaScript التي تعمل من طرف الخادم، وهي مفتوحة المصدر ومتعددة المنصات cross-platform -أي تعمل على أكثر من نظام تشغيل- وهي مبنية على محرك جافاسكربت Chrome V8، وتستعمل أساسيًا لإنشاء خوادم الويب، لكنها ليست محدودةً لهذه المهمة فقط، كما أنها لاقت رواجًا بدءًا من انطلاقها في 2009، وتلعب الآن دورًا مهمًا في عالم تطوير الويب، فإذا عددنا أنّ النجوم التي يحصل عليها المشروع في GitHub معيارًا لشهرة البرمجية، فاعلم أنّ Node.js قد حصدت أكثر من 84 ألفًا من النجوم حتى الآن، ومن الجدير بالذكر أنّ Node.js مبنية على محرك جافاسكربت Chrome V8، كما تُستعمل بصورة أساسية لإنشاء خوادم الويب، لكنها ليست محدودةً لهذه المهمة فقط.

هذا المقال جزء من سلسلة حول Node.js:

• مقدمة إلى Node.js
• استخدام الوضع التفاعلي والتعامل مع سطر الأوامر في Node.js
• دليلك الشامل إلى مدير الحزم npm في Node.js
• كيفية تنفيذ الدوال داخليا ضمن Node.js
• البرمجة غير المتزامنة في Node.js
• التعامل مع الطلبيات الشبكية في Node.js
• التعامل مع الملفات في Node.js
• تعرف على وحدات Node.js الأساسية

أفضل ميزات Node.js

تتميز Node.js بالمزايا التالية:

السرعة

إحدى الميزات التي تشتهر بها Node.js هي السرعة، فشيفرة JavaScript التي تعمل على Node.js اعتمادًا على اختبارات الأداء benchmark يمكن أن تكون بضعفي سرعة تنفيذ اللغات المصرَّفة compiled مثل C أو Java، وأضعاف سرعة اللغات المفسَّرة مثل بايثون أو روبي بسبب نموذج عدم الحجب non-blocking الذي تستعمله.

بسيطة

صدِّقنا عندما نخبرك بأن Node.js بسيطة، بل بسيطة جدًا.

تستعمل JavaScript

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

محرك V8

يمكنك الاستفادة من عمل آلاف المهندسين الذين جعلوا -ويستمروا بجعل- محرك JavaScript الخاص بمتصفح Chrome سريعًا للغاية، وذلك باعتماد Node.js على محرك Chrome V8 المفتوح المصدر.

منصة غير متزامنة

تُعَدّ جميع الأوامر البرمجية في لغات البرمجة التقليدية حاجبة blocking افتراضيًا مثل سي C وجافا Java وبايثون وبي إتش بي PHP إلا إذا تدخّلتَ بصورة صريحة لإنشاء عمليات غير متزامنة؛ فإذا أجريت مثلًا طلبًا شبكيًا لقراءة ملف JSON، فسيتوقف التنفيذ حتى يكون الرد response جاهزًا.

تسمح JavaScript بكتابة شيفرات غير متزامنة asynchronous وغير حاجبة non-blocking بطريقة سهلة جدًا باستخدام خيط thread وحيد ودوال رد النداء callback functions والبرمجة التي تعتمد على الأحداث event-driven، حيث نمرر دالة رد نداء والتي ستُستدعَى حين نتمكن من إكمال معالجة العملية وذلك في كل مرة تحدث عملية تستهلك الموارد، كما أننا لن ننتظر الانتهاء من ذلك قبل الاستمرار في تنفيذ بقية البرنامج.

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

اقتباس

ملاحظة: إذا أنشأتَ المعالج onclick لصفحة الويب، فأنت تستعمل تقنيات البرمجة غير المتزامنة باستخدام معالجات الأحداث في JavaScript.

توفِّر Node.js تعاملًا غير حاجب مع الدخل والخرج I/O، وتكون المكتبات في Node.js عمومًا مكتوبةً بمنهجية عدم الحجب، مما يجعل سلوك الحجب في Node.js استثناءً للقاعدة وليس شيئًا طبيعيًا، كما تكمل Node.js العمليات عند وصول الرد عندما تريد إجراء عملية دخل أو خرج مثل القراءة من الشبكة أو الوصول إلى قاعدة البيانات أو نظام الملفات بدلًا من حجب الخيط blocking the thread وإهدار طاقة المعالج بالانتظار.

عدد هائل من المكتبات

ساعد مدير الحزم npm ببنيته البسيطة النظام العام في node.js، إذ يستضيف npm ما يقرب من 500 ألف حزمة مفتوحة المصدر تستطيع استخدامها بحرّية.

مثال عن تطبيق Node.js

المثال الأكثر شيوعًا عن تطبيق Node.js هو خادم ويب يعرض العبارة الشهيرة Hello World:

const http = require('http') 
const hostname = '127.0.0.1' 
const port = 3000 
const server = http.createServer((req, res) => { 
res.statusCode = 200 
res.setHeader('Content-Type', 'text/plain') 
res.end('Hello World\n') 
}) 
server.listen(port, hostname, () => { 
console.log(`Server running at http://${hostname}:${port}/`) 
}) 

احفظ الشيفرة البسيطة السابقة في ملف باسم server.js ثم نفِّذ node server.js في الطرفية الخاصة بك وذلك من أجل تنفيذ تلك الشيفرة.

تبدأ الشيفرة السابقة بتضمين وحدة http‏، إذ تمتلك Node.js مكتبةً قياسيةً رائعةً بما في ذلك دعم التعامل مع الشبكات؛ أما التابع createServer()‎ الخاص بوحدة http فيُنشئ خادم HTTP جديد ويعيده، كما أنّ الخادم قد ضُبِط للاستماع إلى منفذ وعنوان شبكي محدَّدين، وعندما يجهز الخادم فستُستدعى دالة رد النداء والتي تخبرنا في هذه الحالة أنّ الخادم جاهز، وكلما استقبل الخادم طلبًا request جديدًا، فسيُطلَق الحدث request الذي يوفِّر كائنين هما الطلب أي كائن http.IncomingMessage والرد أي كائن http.ServerResponse، ويُعَدّ هذان الكائنان أساسًا للتعامل مع استدعاء HTTP.

يوفِّر الكائن الأول معلومات الطلبية لكننا لم نستعمله في هذا المثال البسيط، إلا أنه يمكنك الوصول إلى ترويسات الطلب وإلى بيانات الطلب؛ أما الكائن الثاني فيعيد البيانات إلى صاحب الطلب caller، وفي هذه الحالة باستخدامنا للسطر التالي:

res.statusCode = 200

ضبطنا قيمة الخاصية statusCode إلى 200 والتي تعني أنّ الرد ناجح، ثم ضبطنا ترويسة Content-Type كما يلي:

res.setHeader('Content-Type', 'text/plain')

ثم ننهي الطلب بإضافة المحتوى على أساس وسيط argument إلى التابع ‎end()‎:

res.end('Hello World\n')

أدوات Node.js وأطر عملها

تُعَدّ Node.js منصةً منخفضة المستوى، كما توجد آلاف المكتبات المكتوبة باستخدام Node.js لتسهيل الأمور على المطوِّرين وجعلها أكثر متعةً وسلاسةً، إذ أصبح عدد كبير من هذه المكتبات شائعًا بين المطوِّرين، وهذه قائمة غير شاملة للمكتبات التي نراها تستحق التعلم:

• Express: أحد أبسط وأقوى الطرق لإنشاء خادم ويب، ويكون تركيزه على البساطة وعدم الانحياز والميزات الأساسية لخادم الويب هو مفتاح نجاحه.
• Meteor: إطار عمل Framework قوي جدًا ومتكامل، يسمح لك ببناء التطبيقات باستخدام JavaScript ومشاركة الشيفرة بين العميل والخادم، كما أصبح الآن يتكامل بسلاسة مع مكتبات واجهة المستخدِم مثل React و Vue و Angular، في حين يمكن استخدامه أيضًا لإنشاء تطبيقات الويب.
• koa: بناه فريق Express نفسه ويطمح إلى أن يكون أصغر وأبسط اعتمادًا على سنوات الخبرة الطويلة للفريق، إذ بدأ هذا المشروع الجديد للحاجة إلى إنشاء تغييرات غير متوافقة مع ما سبقها دون تخريب ما أُنجِز في المشروع.
• Next.js: إطار عمل يستعمل التصيير rendering من طرف الخادم لتطبيقات React.
• Micro: خادم خفيف جدًا لإنشاء خدمات HTTP مصغرة microservices غير متزامنة.
• Socket.io: محرك تواصل في الوقت الحقيقي لبناء تطبيقات الشبكة.

تاريخ موجز عن Node.js

لننظر إلى تاريخ Node.js من عام 2009 حتى الآن.

أُنشِئت لغة JavaScript في شركة Netscape على أساس أداة لتعديل صفحات الويب داخل متصفحها Netscape Navigator، كما يُعَدّ بيع خوادم الويب جزءًا من نموذج الأعمال في Netscape والتي تحتوي على بيئة باسم Netscape LiveWire التي تستطيع إنشاء صفحات آلية باستخدام JavaScript من طرف الخادم؛ أي أنّ فكرة استخدام JavaScript من طرف الخادم لم تبدأ من Node.js وإنما هي قديمة قدم JavaScript، إلا أنها لم تكن ناجحةً في تلك الفترة.

أحد العوامل الرئيسية لاشتهار Node.js هو التوقيت، إذ بدأت لغة JavaScript تُعَدّ لغةً حقيقيةً، وذلك بفضل تطبيقات Web 2.0 التي أظهرت للعالم كيف تكون التجربة الحديثة للويب مثل Google Maps أو GMail، كما أنّ أداء محركات JavaScript قد ارتفع بشدة بفضل حرب المتصفحات، إذ تعمل فرق التطوير خلف كل متصفح رئيسي بجدّ كل يوم لتحسين الأداء، وكان هذا فوزًا عظيمًا لمنصة JavaScript، علمًا أنّ محرك V8 الذي تستعمله Node.js هو محرك متصفح Chrome، وبالطبع لم تكن شهرة Node.js محض صدفة أو توقيت جيد، إذ أضافت مفاهيم ثورية في كيفية البرمجة باستخدام JavaScript من طرف الخادم.

• عام 2009: ولدت Node.js وأُنشِئت أول نسخة من npm.
• عام 2010: ولد كل من Express وSocket.io.
• عام 2011: وصل npm إلى الإصدار 1.0 وبدأت الشركات الكبيرة بتبني Node.js مثل LinkedIn، كما ولد Hapi.
• عام 2012: استمرت عملية تبنّي Node.js بسرعة كبيرة.
• عام 2013: أُنشِئت أول منصة تدوين باستخدام Node.js: ولدت Koa.
• عام 2014: اشتق مشروع IO.js من Node.js بهدف إضافة دعم ES6 والتطوير بوتيرة أسرع.
• عام 2015: أُسست منظمة Node.js Foundation، ودمج مشروع IO.js مع Node.js مجددًا، كما أصبح npm يدعم الوحدات الخاصة private modules، وأُصدرت نسخة Node 4 (ولم تُصدَر النسخة 1 أو 2 أو 3 من قبل).
• عام 2016: ولد مشروع Yarn، وأُصدِرت Node 6.
• عام 2017: ركّز npm على الحماية أكثر، وأُصدرت Node 8، وأضاف محرك V8 وحدة HTTP/2 بنسخة تجريبية.
• عام 2018: أُصدرت Node 10، وأضيف دعم تجريبي لوحدات ES بلاحقة ‎.mjs.
• عام 2019: أُصدرت Node 12 وNode 13.
• عام 2020: أُصدرت Node 14.
• عام 2021: الإصدار الحالي هو 16 والذي أصبح الإصدار المستقر طويل الدعم LTS حاليًا.

كيفية تثبيت Node.js

يمكن تثبيت Node.js بطرائق مختلفة، وسنشرح في هذا الفصل أشهر الطرائق وأسهلها لتثبيتها، كما أنّ الحزم الرسمية لجميع أنظمة التشغيل الرئيسية متوافرة على الرابط nodejs.org/en/download.

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

brew install node

يُعَدّ nvm الطريق الشائع لتشغيل Node.js، إذ يسمح لك بتبديل إصدار Node.js بسهولة وتثبيت الإصدارات الجديدة لتجربتها ثم العودة إلى الإصدار القديم إذا لم يعمل كل شيء على ما يرام، فمن المفيد جدًا على سبيل المثال تجربة الشيفرة الخاصة ببرنامج على الإصدارات القديمة من Node.js، كما ننصحك بمراجعة github.com/creationix/nvm لمزيد من المعلومات حول هذا الخيار، وننصحك بصورة شخصية باستعمال المثبِّت الرسمي إذا أنت حديث العهد على Node.js ولا تريد استخدام مدير الحزم الخاص بنظام تشغيلك، لكن على أي حال، سيكون البرنامج التنفيذي node متاحًا في سطر الأوامر بعد تثبيت Node.js بأي طريقة من الطرائق السابقة.

ماذا عليك معرفته في JavaScript لاستخدام Node.js

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

• بنية البرنامج.
• التعابير.
• الأنواع.
• المتغيرات
• الدوال والدوال السهمية.
• الكلمة المحجوزة this.
• حلقات التكرار والمجالات scopes.
• المصفوفات.
• الفواصل المنقوطة (نعم، هذا المحرف ; ? )
• الوضع الصارم.
• إصدارات ECMAScript مثل ES6 وES2016 وES2017.

ستكون بعد تعلّمك للمفاهيم السابقة في طريقك لتصبح مطور JavaScript محترف في بيئة المتصفح وNode.js، وفيما يلي مفاهيم أساسية لفهم البرمجة غير المتزامنة asynchronous programming والتي هي جزء أساسي من Node.js:

• مفهوم البرمجة غير المتزامنة ورد النداء callbacks.
• المؤقتات Timers.
• الوعود Promises.
• الكلمتان المحجوزتان Async وAwait.
• التعابير المغلقة Closures.
• حلقات الأحداث.

توجد مقالات كثيرة وكتب في أكاديمية حسوب بالإضافة إلى توثيق JavaScript في موسوعة حسوب عن جميع المواضيع السابقة.

الاختلافات بين Node.js والمتصفح

كيف تختلف كتابة تطبيقات JavaScript في Node.js عن البرمجة للويب داخل المتصفح؟ يستخدِم كل من المتصفح وNode.js لغة JavaScript للبرمجة؛ لكن بناء التطبيقات التي تعمل في المتصفح مختلف تمامًا عن بناء تطبيقات Node.js، فعلى الرغم من أنهما يستعملان لغة البرمجة نفسها JavaScript، إلا أنه هنالك اختلافات جوهرية تجعل الفرق بينهما كبيرًا،.

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

ستتعامل أغلب الوقت في المتصفح مع شجرة DOM أو غيرها من الواجهات البرمجية الخاصة بالمتصفح Web Platform APIs مثل ملفات الارتباط Cookies والتي لا توجد في Node.js، وبالطبع لن تكون الكائنات document وwindow وغيرها من كائنات المتصفح متوافرةً، كما لن نحصل على الواجهات البرمجية APIs التي توفرها Node.js عبر وحداتها مثل الوصول إلى نظام الملفات.

يوجد اختلاف كبير آخر وهو أنك تستطيع التحكم في البيئة التي تعمل فيها Node.js ما لم تبني تطبيقًا مفتوح المصدر يمكن لأي شخص نشره في أيّ مكان، فأنت تعلم ما هي نسخة Node.js التي سيعمل عليها تطبيقك؛ فليس لديك الحرية في اختيار المتصفح الذي يستخدمه زوار موقعك بموازنة ذلك مع بيئة المتصفح، وهذا يعني أنك يمكنك أن تكتب شيفرات ES6-7-8-9 التي تدعمها نسخة Node.js عندك.

ستكون ملزمًا باستخدام إصدارات JavaScript/ECMAScript القديمة على الرغم من تطوّر JavaScript بسرعة كبيرة، وذلك لأن المتصفحات أبطأ منها والمستخدِمون أبطأ بالتحديث، وصحيحٌ أنك تستطيع استخدام Babel لتحويل شيفرتك إلى نسخة موافقة لمعيار ECMAScript 5 قبل إرسالها إلى زوار موقعك، لكنك لن تحتاج إلى ذلك في Node.js.

يوجد اختلاف آخر هو استخدام Node.js لنظام الوحدات CommonJS، بينما بدأنا نرى أنّ المتصفحات تستخدم معيار وحدات ES Modules؛ وهذا يعني عمليًا أنه عليك استخدام require()‎ في Node.js، وimport في المتصفح حاليًا.

محرك V8

V8 هو اسم محرك JavaScript الذي يُشغِّل متصفح Chrome، حيث يأخذ شيفرات JavaScript وينفذها أثناء التصفح عبر Chrome، إذ يوفر بيئة التشغيل اللازمة لتنفيذ شيفرات JavaScript، في حين يوفِّر المتصفح شجرة DOM وغيرها من الواجهات البرمجية للويب، كما يُعَدّ استقلال محرك JavaScript عن المتصفح الذي يستخدمه الميزة الرئيسية التي سببت بانتشار Node.js.

اختار مجتمع مطوري Node.js محرك V8 في 2009، وبعد أن ذاع صيت Node.js صار محرك V8 هو المحرك الذي يشغِّل عددًا غير محصور من شيفرات JavaScript التي تعمل من طرف الخادم، وخذ بالحسبان أنّ بيئة تشغيل Node.js كبيرة جدًا ويعود الفضل إليها في أنّ محرك V8 أصبح يشغِّل تطبيقات سطح المكتب عن طريق مشاريع مثل Electron.js.

محركات JavaScript الأخرى

تملك المتصفحات الأخرى محركات JavaScript مختلفة منها:

• يملك متصفح Firefox محرك SpiderMonkey.
• يملك متصفح Safari محرك JavaScriptCore ويسمى Nitro أيضًا.
• يملك متصفح Edge محرك Chakra.

تطبِّق جميع هذه المحركات معيار ECMA ES-262 والذي يسمى ECMAScript أيضًا، وهو المعيار المستخدَم في لغة JavaScript.

السعي إلى الأداء الأفضل

كُتِب محرك V8 بلغة C++‎ ويُحسَّن باستمرار، وهو محمول portable ويعمل على ماك ولينكس وويندوز وغيرها من أنظمة التشغيل، كما لن نخوض في تفاصيل محرك V8 لأنها موجودة في مواقع كثيرة مثل موقع V8 الرسمي وتتغير مع مرور الوقت، وعادةً تكون التغييرات كبيرةً، إذ يتطور محرك V8 دومًا كما في غيره في محركات JavaScript لتسريع الويب وبيئة Node.js، كما يجري سباق في عالم الويب للأداء الأفضل منذ سنوات، ونحن -المستخدِمون والمطوِّرون- نستفيد كثيرًا من هذه المنافسة لأنها تعطينا أداءً أسرع وأفضل سنةً بعد سنة.

التصريف Compilation

تُعَدّ لغة JavaScript عمومًا لغةً مفسَّرةً interpreted؛ لكن محركات JavaScript الحديثة لم تَعُد تفسِّر شيفرات JavaScript وحسب، وإنما تُصرِّفها compile، فقد حدث ذلك منذ عام 2009، عندما أُضيف مُصرِّف SpuderMonkey إلى متصفح Firefox 3.5، ثم اتبع الجميع هذه الفكرة، حيث تُصرَّف JavaScript داخليًا في V8 حين اللزوم بتصريف JIT (اختصارًا لـ just-in-time) لتسريع عملية التنفيذ.

قد ترى أنّ ذلك مناف للمنطق، لكن تطورت لغة JavaScript من لغة تنفِّذ عادةً بضعة مئات من الأسطر إلى لغة تشغِّل تطبيقات كاملة تحتوي على آلاف أو حتى مئات الآلاف من الأسطر البرمجية التي تعمل في المتصفح وذلك منذ إطلاق Google Maps في 2004، فيمكن لتطبيقاتنا الآن أن تعمل لساعات في المتصفح بدلًا من سكربتات بسيطة للتحقق من صحة المدخلات أو إجراء أفعال بسيطة معينة، ففي هذا العالم الجديد أصبح من المنطقي تمامًا تصريف شيفرات JavaScript؛ وصحيحٌ أنها قد تأخذ بعض الوقت القليل لجهوزية شيفرة JavaScript، إلا أننا سنرى أداءً أفضل من الشيفرة المفسَّرة فقط.

تشغيل تطبيق Node.js والخروج منه

الطريقة التقليدية لتشغيل برنامج Node.js هي استخدام الأمر node المتاح في نظام التشغيل بعد تثبيت Node.js ثم تمرير اسم الملف الذي تريد تنفيذه إلى الأمر، فلو كان تطبيق Node.js عندك موجود في ملف باسم app.js، فيمكنك تشغيله بكتابة الأمر التالي في سطر الأوامر:

node app.js

لنتعلم كيف يمكننا إنهاء تطبيق Node.js بأفضل الطرائق الممكنة، حيث توجد عدة طرق لإنهائه، فعندما تشغِّل برنامج في سطر الأوامر، يمكنك أن توقفه بالضغط على Ctrl+c، لكن ما نريد الحديث عنه هو إنهاء التطبيق برمجيًا، ولنبدأ بأكثر طريقة قاسية لإنهاء التطبيق، ولنرَ لماذا لا يفترض بك استعمالها.

توفِّر الوحدة الأساسية core module المسماة process تابعًا يسمح لك بالخروج برمجيًا من تطبيق Node.js وهو process.exit()‎، إذ سيؤدي تشغيل Node.js هذا السطر إلى إغلاق العملية process مباشرةً، وهذا يعني أنه سيتوقف أيّ رد نداء معلَّق، أو أيّ طلب شبكي لا يزال مُرسَلًا، أو أيّ وصول إلى نظام ملفات، أو عمليات تكتب إلى مجرى الخرج القياسي stdout أو الخطأ القياسي stderr توقفًا مباشرًا دون سابق إنذار، وإذا لم تجد حرجًا في ذلك، فيمكنك تمرير عدد صحيح إلى التابع ليخبر نظام التشغيل ما هي حالة الخروج exit code:

process.exit(1)

تكون حالة الخروج الافتراضية هي 0، والتي تعني نجاح تنفيذ البرنامج، حيث تمتلك حالات الخروج المختلفة معانٍ خاصة والتي يمكنك استخدامها في نظامك للتواصل مع بقية البرامج، كما يمكنك أيضًا ضبط قيمة الخاصية process.exitCode بحيث تُعيد Node.js حالة الخروج المضبوطة إلى هذه الخاصية عند انتهاء تنفيذ البرنامج:

process.exitCode = 1

ينتهي البرنامج بسلام عند انتهاء تنفيذ جميع الشيفرات فيه في الحالة الطبيعية، وكثيرًا ما نُنشِئ خوادم باستخدام Node.js مثل خادم HTTP التالي:

const express = require('express')
const app = express()
app.get('/', (req, res) => {
 res.send('Hi!')
})
app.listen(3000, () => console.log('Server ready'))

لن ينتهي هذا البرنامج أبدًا، فإذا استدعيت التابع ‎process.exit()‎‎، فستنتهي جميع الطلبيات قيد التنفيذ أو المعلَّقة، وهذا ليس أمرًا جميلًا صدقًا، حيث ستحتاج في هذه الحالة إلى إرسال الإشارة SIGTERM إلى الأمر، وسنتعامل مع الأمر باستخدام معالج إشارة العملية process signal handler.

اقتباس

ملاحظة: لا حاجة إلى تضمين الوحدة process باستخدام require، فهي متاحة تلقائيًا.

const express = require('express')
const app = express()
app.get('/', (req, res) => {
 res.send('Hi!')
})
app.listen(3000, () => console.log('Server ready'))
process.on('SIGTERM', () => {
 app.close(() => {
   console.log('Process terminated')
 })
})

قد تتساءل ما هي الإشارات؟ الإشارات هي نظام تواصل داخلي في معيار POSIX، وهو إشعار يُرسَل إلى العملية لإخبارها أنّ حدثًا ما قد حدث، فالإشارة SIGKILL هي الإشارة التي تخبر العملية بالتوقف عن العمل فورًا، وهي تعمل مثل ‎process.exit()‎؛ أما الإشارة SIGTERM فهي الإشارة التي تخبر العملية بأن تنتهي بلطف، وهي الإشارة التي تُرسَل من مدراء العمليات في أنظمة التشغيل، كما يمكنك إرسال هذه الإشارة من داخل البرنامج باستخدام دالة تابع آخر:

process.kill(process.pid, 'SIGTERM') 

أو من برنامج Node.js آخر، أو من أيّ برنامج يعمل على النظام يعرف مُعرِّف العملية PID الخاص بالعملية التي تريد إنهاءها.

متغيرات البيئة: الفرق بين التطوير والإنتاج

متغير البيئة هو اصطلاح مُستخدَم على نطاق واسع في المكتبات الخارجية أيضًا، وسنتعلم كيفية قراءة واستخدام متغيرات البيئة في برنامج Node.js، حيث توفِّر الوحدة الأساسية process في Node.js الخاصية env التي تحتوي على جميع متغيرات البيئة المضبوطة في لحظة تشغيل العملية، وفيما يلي مثال يصل إلى متغير البيئة NODE_ENV المضبوط إلى القيمة development افتراضيًا:

process.env.NODE_ENV // "development"

ضبطه إلى القيمة production قبل تشغيل السكربت سيخبر Node.js أنّ هذه بيئة إنتاجية وليست تطويرية، كما يمكنك بالطريقة نفسها الوصول إلى أيّ متغيرات بيئة خاصة تضبطها.

يمكن أن يكون لديك إعدادات مختلفة لبيئات الإنتاج والتطوير، حيث يفترض Node أنه يعمل دائمًا في بيئة تطوير، ولكن يمكنك إعلام Node.js بأنك تعمل في بيئة إنتاج من خلال ضبط متغير البيئة NODE_ENV=production عن طريق تنفيذ الأمر التالي:

export NODE_ENV=production

لكن يُفضَّل في الصدَفة shell وضعه في ملف إعداد الصدَفة مثل ‎.bash_profile مع صدفة Bash، وذلك لأن الإعداد بخلاف ذلك لا يستمر في حالة إعادة تشغيل النظام، كما يمكنك تطبيق متغير البيئة عن طريق وضعه في بداية أمر تهيئة تطبيقك كما يلي:

NODE_ENV=production node app.js

يضمن ضبط البيئة على القيمة production ما يلي:

• الاحتفاظ بتسجيل الدخول إلى المستوى الأدنى الأساسي.
• إجراء مزيد من مستويات التخبئة أو التخزين المؤقت caching لتحسين الأداء.

تطبِّق مكتبة القوالب Pug التي يستخدمها إطار عمل Express على سبيل المثال عملية التصريف في وضع تنقيح الأخطاء، إذا لم يُضبَط المتغير NODE_ENV على القيمة production، حيث تُصرَّف عروض Express في كل طلب في وضع التطوير، بينما تُخزَّن مؤقتًا في وضع الإنتاج، كما يوفِّر إطار Express خطّافات إعداد configuration hooks خاصة بالبيئة تُستدعَى تلقائيًا بناءً على قيمة المتغير NODE_ENV:

app.configure('development', () => {
 //...
})
app.configure('production', () => {
 //...
})
app.configure('production', 'staging', () => {
 //...
})

يمكنك استخدام ذلك مثلًا لضبط معالجات أخطاء مختلفة في وضع مختلف كما يلي:

app.configure('development', () => {
 app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));
})

app.configure('production', () => {
 app.use(express.errorHandler())
})

استضافة مشاريع Node.js

يمكن استضافة تطبيقات Node.js في أماكن عديدة اعتمادًا على احتياجاتك، وسنذكر لك قائمةً بالخيارات المتاحة أمامك، وهي قائمة غير شاملة بالخيارات التي يمكنك استخدامها لنشر تطبيقك وجعله متاحًا للعامة، وسنرتِّبها من الأبسط والأقل مزايا إلى الأعقد والأقوى:

• أسهل الخيارات على الإطلاق: نفق محلي local tunnel.
• نشر التطبيقات دون أي ضبط.
• Glitch.
• Codepen.
• الخيارات عديمة الخوادم Serverless.
• المنصة على أساس خدمة PAAS.
• Zeit Now.
• Nanobox.
• Heroku.
• Microsoft Azure.
• Google Cloud Platform.
• خادم خاص افتراضي Virtual Private Server أي VPS.
• خادم حقيقي Bare metal.

نفق محلي

يمكنك نشر تطبيقك وتُخديم الطلبات من حاسوبك باستخدام نفق محلي local tunnel حتى إذا كان لديك عنوان IP ديناميكي، أو كنت تحت NAT، فهذا الخيار مناسب لإجراء بعض الاختبارات السريعة، أو تجربة المنتج أو مشاركة التطبيق مع مجموعة صغيرة من الأشخاص، وهنالك أداة رائعة لذلك متاحة لجميع المنصات اسمها ngrok، فكل ما عليك فعله لاستعمالها هو كتابة ngrok PORT، إذ إنَّ PORT هو المنفذ الذي تريد نشره على الإنترنت، وستحصل على نطاق من ngrok.io، لكن سيسمح لك الاشتراك المدفوع بالحصول على عنوان URL مخصص إضافةً إلى خيارات حماية إضافة (تذكَّر أنك تفتح جهازك إلى الإنترنت)، وهنالك خدمة أخرى يمكنك استخدامها وهي github.com/localtunnel/localtunnel.

نشر التطبيقات دون أي ضبط

هناك خيارات متاحة لنشر تطبيقات Node.js دون أيّ ضبط يُذكر، وسنذكر من هذه الخيارات منصة Glitch ومنصة Codepen.

Glitch

يُعَدّ Glitch بيئةً تسمح لك ببناء تطبيقاتك بسرعة كبيرة، ورؤيتها حيةً على النطاق الفرعي الخاص بك على glitch.com، فلا يمكنك حاليًا الحصول على نطاق مخصص وهنالك بعض المحدوديات، لكن ستبقى مع ذلك بيئةً رائعةً؛ فهي تحتوي على كامل ميزات Node.js وCDN ومكان تخزين آمن للمعلومات الحساسة، بالإضافة إلى الاستيراد والتصدير من GitHub، كما أنّ هذه الخدمة موفَّرة من الشركة التي تقف خلف FogBugz وTrello والمشاركين في إنشاء StackOverflow.

Codepen

منصة Codepen رائعة، فهي تسمح لك بإنشاء مشروع متعدد الملفات ونشره بنطاق مخصص.

الخيارات عديمة الخوادم Serverless

إحدى الطرائق لنشر تطبيقك وعدم الحاجة إلى خادم لإدارته هي استخدام إحدى الخيارات عديمة الخوادم Serverless التي هي منهجية لنشر تطبيقاتك على أساس وظائف functions، وهي ترد على نقطة نهاية شبكية network endpoint، وهذا يسمى أيضًا FAAS أي الوظيفة على أساس خدمة Function As A Service، ومن الخيارات الشائعة جدًا هي:

• Serverless Framework
• Standard Library

يوفِّر كلا الخيارين طبقة تجريدية abstraction layer لنشر التطبيقات على حلول مثل AWS Lambda وغيرها من حلول FAAS المبنية على Azure أو Google Cloud.

المنصة على أساس خدمة PAAS

تُعَدّ PASS اختصارًا لـ Platform AS A Service أي المنصة على أساس خدمة، وتحمل عنك هذه المنصات عناء التفكير في كثير من الأمور عند نشر تطبيقك.

Zeit Now

يُعَدّ Zeit خيارًا مثيرًا للاهتمام، فعندما تكتب الأمر now في الطرفية، فسيتولى أمر نشر تطبيقك كله؛ وهنالك نسخة مجانية مع محدوديات ونسخة مدفوعة بميزات أكثر، حيث ستنسى أنّ هنالك خادم وكل ما عليك فعله هو نشر التطبيق.

Nanobox

سنحيلك إلى موقع Nanobox لتأخذ فكرةً عنه nanobox.io.

Heroku

يُعَدّ Heroku منصةً رائعةً، وهنالك سلسلة فيديوهات عن كيفية نشر التطبيقات عبر Heroku منها فيديو نشر تطبيق React.js ذو واجهات خلفية Node.js على منصة Heroku.

Microsoft Azure

خدمة Azure توفرها Microsoft Cloud، وهنالك مقالة أجنبية تفصيلية عن إنشاء تطبيق Node.js في Azure.

Google Cloud Platform

تُعَدّ منصة Google Cloud خيارًا رائعًا لتنظيم تطبيقاتك، ولديهم توثيق جيد عن Node.js.

خادم خاص افتراضي VPS

ستجد في هذا القسم الخيارات الشائعة التي قد تعرفها من قبل، وهي مرتبة من أكثرها سهولةً للمستخدِم:

• DigitalOcean
• Linode
• Amazon Web Services، ونذكر خصوصًا خدمة Amazon Elastic Beanstalk فهي تسهل بعضًا من تعقيدات AWS.

ولمّا كانت هذه الخدمات توفِّر لك خادم لينكس فارغ يمكنك العمل عليه، فلن نوصي بمقالةٍ أو دليلٍ محدد لهذه الخدمات؛ وهذه ليست جميع الشركات التي توفر خدمات VPS، لكنها هي التي استعملناها سابقًا وننصح بها.

خادم حقيقي

يوجد خيار آخر هو خادم حقيقي bare metal، بحيث تثبت عليه توزيعة لينكس وتصله بالإنترنت أو يمكنك استئجار واحد شهريًا، كما في خدمة Vultr Bare Metal.

ترجمة -وبتصرّف- للفصلين Introduction و Basics من كتاب The Node.js handbook لصاحبه Flavio Copes.

اقرأ أيضًا

• المقال التالي: استخدام الوضع التفاعلي والتعامل مع سطر الأوامر في Node.js
• بناء تطبيق Node.js باستخدام Docker
• إعداد تطبيق node.js لسير عمل يعتمد على الحاويات باستخدام Docker Compose
• تأمين تطبيق Node.js يعمل على الحاويات باستخدام Nginx و Let’s Encrypt و Compose Docker
• نشر تطبيق Node.js على الويب: خدمة هيروكو (Heroku) مثالًا

يسمح تقييد معدل التراسل Rate limiting بإدارة حركة مرور البيانات في الشبكة، ويحد من عدد المرات التي يكرر فيها المستخدم عملية ما خلال مدة معينة، مثل استخدام واجهة برمجة التطبيقات API. تُعد الخدمات التي لا تحتوي على إجراءات أمان لتقيد من معدل التراسل معدل التراسل عرضة لزيادة التحميل وإعاقة العمل السليم للتطبيق.

سنتعلم في هذا المقال كيفية إنشاء خادم Node.js قادر على التحقق من عنوان IP الخاص بالطلب وحساب معدل هذه الطلبات من خلال مقارنة العلامات الزمنية للطلبات لكل مستخدم، فإذا تجاوز عنوان IP الحد المعين الذي اخترناه في تطبيقنا، فسوف نتصل بواجهة برمجة تطبيقات Cloudflare API ونضيف عنوان IP إلى القائمة، بعدها سننشئ قاعدة جدار حماية Cloudflare Firewall تحظر جميع الطلبات الواردة من عناوين IP الموجودة في تلك القائمة.

إذًا سننشئ مشروع Node.js على منصة تطبيقات DigitalOcean التي تدعي App Platform والتي تحمي النطاقات المسجلة والمضافة إلى حسابك في Cloudflare بتقيد معدل التراسل.

ستحتاج خلال هذا المقال إلى:

• حساب Cloudflare، ويفي الحساب المجاني Free plan من Cloudflare بالغرض. احرص اختيار الحساب المجاني عند إنشاء حساب جديد.
• نطاق مسجل ومضاف إلى حسابك في Cloudflare. يمكنك الإطلاع على كيف نخفف من هجمات DDoS ضد موقعنا باستخدام CloudFlare مع Cloudflare، وننصح بقراءة هذا المقال للتعرف على أساسيات نظام أسماء النطاقات DNS ومكوناته.
• خادم Express مع بيئة Node.js، اتبع الخطوات في المقال التالي لإعداد خادم Express.
• حساب على GitHub ونسخة مثبتة من برنامج gitعلى جهازك، يُعد ذلك ضروريًا لأننا سنرسل الشيفرة من GitHub على منصة App Platform من DigitalOcean.
• حساب على موقع DigitalOcean.

إعداد المشروع والنشر على منصة App Platform

سنوسع خادم Express الأساسي الذي أنشأناه في مقال دليل استخدام Node.js وإطار العمل Express للمبتدئين، في هذه الخطوة، ونرسل الشيفرة إلى مستودع GitHub Repository، ثم ننشر التطبيق على منصة App Platform.

افتح مجلد مشروع خادم Express بواسطة إحدى محررات النصوص البرمجية، ثم أنشئ ملفًا جديدًا في المجلد الرئيسي للمشروع باسم getignore.، وأضف الأسطر التالية:

node_modules/
.env

لاحظ أن السطر الأول في ملف getignore. يوجه git لعدم تتبع المجلد node_modules، ويتيح ذلك عدم زيادة حجم المستودع، إذ يُولَد المجلد node-modules عند الحاجة باستخدام الأمر npm install، أما السطر الثاني فيمنع تتبع ملف متغيرات البيئة، وسوف ننشئ الملف env. في الخطوات التالية.

انتقل إلى ملف server.js في محرر النصوص البرمجية وعدل الأسطر التالية:

...
app.listen(process.env.PORT || 3000, () => {
    console.log(`Example app is listening on port ${process.env.PORT || 3000}`);
});

يتيح الاستخدام الشرطي للمتغير PORT تشغيل الخادم ديناميكيًا على المنفذ المعين PORT في متغير البيئة process.env أو استخدام المنفذ 3000 كمنفذ احتياطي.

لاحظ أن السلسلة الموجودة في التابع console.log ليست محاطة بعلامة اقتباس عادية وإنما بعلامة اقتباس مائلة (`) ، إذ يتيح ذلك استخدام القوالب النصية template literals التي تسمح باستخدام التعابير expressions ضمن السلاسل.

شَغّل التطبيق من واجهة الطرفية Terminal باستخدام الأمر التالي:

node server.js

لاحظ أن واجهة المتصفح ستعرض الرسالة التالية: "Successful response" أي أنه نجحت الاستجابة، وسيظهر الخرج التالي في واجهة الطرفية:

Example app is listening on port 3000

سننشر الآن التطبيق على منصة App platform بعد أن تأكدنا من عمل خادم Express بنجاح.

أولاً ، هيئ git في المجلد الرئيسي للمشروع وأرسل الشيفرة إلى حسابك في GitHub، ثم انتقل إلى لوحة التحكم Dashboard في منصة App Platform في المتصفح وانقر على زر إنشاء التطبيق Create App. ثم اضغط على خيار GitHub وتوثيق مع GitHub، ثم اختر مستودع مشروعك من القائمة المنسدلة.

راجع الإعدادات، ثم سمي التطبيق، وبما أننا سنعمل على مرحلة تطوير التطبيق في هذا المقال يُفضل أن نختار الخطة الأساسية Basic Plan، ثم اضغط على زر تشغيل التطبيق Launch App.

انتقل بعد ذلك إلى صفحة الإعدادات Settings واضغط على قسم النطاقات Domains ثم أضف النطاق الخاص بك الموجه بواسطة Cloudflare في حقل اسم النطاق الرئيسي أو الفرعي Domain or Subdomain Name، ثم اضغط على خيار إدارة النطاق الخاص بك You manage your domain وانسخ سجل CNAME لتضيفه إلى حساب DNS الخاص بنطاقك في Cloudflare.

افتح لوحة تحكم النطاق في Cloudflare في علامة تبويب جديدة، ثم اضغط على تبويبة DNS، واضغط بعدها على زر إضافة سجل Add Record واختر CNAME عند خيار النوع Type، اكتب الرمز @ ثم الصق سجل CNAME الذي نسخته سابقًا من منصة App Platform. اضغط على زر الحفظ Save ثم انتقل إلى صفحة الإعدادات Settings في لوحة تحكم App platform واضغط بعدها على قسم النطاقات Domains، ثم اضغط على زر إضافة نطاق Add Domain.

اضغط على علامة تبويب عمليات النشر Deployments لمشاهدة تفاصيل التطبيقات المنشورة. يمكنك الضغط على نطاقك your_domain لاستعراضه في المتصفح، حالما ينتهي النشر. لاحظ أن واجهة المتصفح ستعرض الرسالة التالية: نجحت الاستجابة "successful response".

ستحصل على الرسالة التالية عند الانتقال إلى علامة تبويب سجلات التشغيل الحالية Runtime Logs في لوحة تحكم App Platform:

Example app is listening on port 8080

لاحظ أن المنفذ 8080 هو المنفذ الافتراضي في App Platform، يمكنك تغييره من الإعدادات قبل النشر.

الآن، سنتعلم كيفية تحديد ذاكرة التخزين المؤقت cache لحساب الطلبات الواردة إلى مُقيِّد معدل التراسل Rate limiter.

تخزين عنوان IP المستخدم وحساب عدد الطلبات في الثانية

سنخزن في هذه الخطوة عنوان IP المستخدم في ذاكرة تخزين مؤقتة cache مع مجموعة من الطوابع الزمنية timestamps لمراقبة عدد الطلبات في الثانية من عنوان IP لكل مستخدم.

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

سنحتاج إلى ثلاثة حزم من برنامج مدير الحزم npm وهي node-cache وis-ip و request-ip. فتلتقط الحزمة request-ip عنوان IP المستخدم الذي يطلب الخادم، أما الحزمة node-cache فتنشئ ذاكرة تخزين مؤقتة تستخدم لتتبع طلبات المستخدم، وتستخدم الحزمة is-ip للتحقق فيما إذا كان عنوان IP هو عنوان IPv6.

ثبت الحزم node-cache وis-ip و request-ip في الطرفية باستخدام مدير الحزم npm عن طريق الأمر التالي:

npm i node-cache is-ip request-ip

افتح ملف server.js بواسطة إحدى محررات النصوص البرمجية وأضف الأسطر التالية بعد سطر const express = require('express');‎:

...
const requestIP = require('request-ip');
const nodeCache = require('node-cache');
const isIp = require('is-ip');
...

يحضّر السطر الأول وحدة requestIP من حزمة request-ip التي ثبتها سابقًا، فتقوم هذه الوحدة بإلتقاط عنوان IP المستخدم الذي يطلب الخادم.

أما السطر الثاني فيحضّر وحدة nodeCache من حزمة node-cache، التي تنشئ ذاكرة تخزين مؤقتة تستخدم لتتبع طلبات المستخدم في الثانية. ويحضّر السطر الثالث وحدة isIp من الحزمة is-ip، ويتحقق فيما إذا كان عنوان IP من الإصدار السادس IPv6 الذي سوف تصوغه وفق ترميز CIDR المعتمد في Cloudflare.

عَرِّف المتغيرات الثابتة في ملف server.js:

...
const TIME_FRAME_IN_S = 10;
const TIME_FRAME_IN_MS = TIME_FRAME_IN_S * 1000;
const MS_TO_S = 1 / 1000;
const RPS_LIMIT = 2;

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

ويحدد المتغير الثابت TIME_FRAME_IN_MS الفترة التي يحسب خلالها تطبيقك متوسط الطوابع الزمنية للمستخدم، ولكن بالميللي ثانية، وسنستخدم معامل التحويل MS_TO_S لتحويل الزمن من صيغة الميللي ثانية إلى صيغة الثواني. يحدد المتغير RPS_LIMIT حد العتبة الذي سيؤدي إلى تشغيل مقيد معدل التراسل، ويغير قيمة العتبة وفقًا لمتطلبات التطبيق، وقد أسندنا له القيمة 2 والتي تعتبر قيمة معتدلة، في المتغير RPS_LIMIT أثناء مرحلة التطوير.

يمكنك باستخدام إطار العمل Express كتابة دوال وسيطة middleware لها وصول إلى جميع طلبات HTTP الواردة إلى خادمك.

استدعِ التابع ()app.use لتعريف دالة وسيطة، ومررها ضمنه، باتباع هذه الطريقة أنشئ دالة وسيطة باسم ipMiddleware:

...
const ipMiddleware = async function (req, res, next) {
    let clientIP = requestIP.getClientIp(req);
    if (isIp.v6(clientIP)) {
        clientIP = clientIP.split(':').splice(0, 4).join(':') + '::/64';
    }
    next();
};
app.use(ipMiddleware);
...

لاحظ أن الدالة ()getClientIP تستخدم الكائن req من الدالة الوسيطة كمعامل.

نستدعي الدالة ()v6. مع الوحدة is-ip، وتعطي نتيجة صحيحة true إذا كان الوسيط الممرر إليها عنوان IPv6. يجب عليك صياغة عناوين IPv6 وفق قناع شبكة 64/ حسب ترميز CIDR، كالآتي:

aaaa:bbbb:cccc:dddd::/64

ينشئ التابع (':')split. مصفوفة من السلسلة التي تحتوي على عناوين IP ويفصلهم بواسطة المحرف:.

يرجع التابع (splice(0,4. أول أربعة وسطاء في المصفوفة. أما التابع (':')join. فيرجع سلسلة من المصفوفة مع المحرف :.

يوجه التابع ()next الدالة الوسيطة للانتقال إلى الدالة الوسيطة التالية، إن وجدت، ونلاحظ في مثالنا أنها تنقل الطلب إلى المسار / من طلب GET. احرص على تضمين ذلك في التابع، وإلا فلن ينتقل الطلب من الدالة الوسيطة.

هيئ نسخة instance من الوحدة node-cache عن طريق إضافة المتغير التالي بعد الثوابت:

...
const IPCache = new nodeCache({ stdTTL: TIME_FRAME_IN_S, deleteOnExpire: false, checkperiod: TIME_FRAME_IN_S });
...

يمكننا إعادة تعريف المعاملات overriding الأساسية الخاصة بوحدة nodecache وتبديلها إلى خصائص محددة custom properties باستخدام المتغير الثابت IPCache:

• stdTTL: يعبر عن الفاصل الزمني بالثواني الذي يُحذَف بعده زوج مفتاح-قيمة key-value من عناصر ذاكرة التخزين المؤقت. TTL تعني وقت الحياة Time To Live، وهي مقياس للوقت الذي تنتهي بعده ذاكرة التخزين المؤقت.
• deleteOnExpire: اضبطه على falseحيث أننا سنكتب تابع استدعاء فيما بعد ليتعامل مع الحدث expired.

*checkperiod يعبر عن الفاصل الزمني بالثواني الذي يُشغَل بعده فحص تلقائي للعناصر منتهية الصلاحية. تكون القيمة الإفتراضية 600، لكن فحص انتهاء الصلاحية في تطبيقك سيحدث في وقت أقصر، لأن القيمة المحددة أصغر.

يمكنك الإطلاع على توثيق node-cache للحصول على مزيد من المعلومات عن المعاملات الإفتراضية لحزمة node-cache. سيساعدك المخطط التالي على تصور كيفية تخزين ذاكرة التخزين المؤقت للبيانات:

سننشئ الآن زوج مفتاح-قيمة لعنوان IP الجديد ونضيفه للزوج القديم في حال وجود عنوان IP في الذاكرة المؤقتة. تكون القيمة عبارة عن مصفوفة من العلامات الزمنية timestamps المقابلة لكل طلب وارد إلى تطبيقك.

أنشئ الدالة ()updateCache بعد المتغير الثابت IPCache لإضافة علامات زمنية للطوابع في الذاكرة المؤقتة:

...
const updateCache = (ip) => {
    let IPArray = IPCache.get(ip) || [];
    IPArray.push(new Date());
    IPCache.set(ip, IPArray, (IPCache.getTtl(ip) - Date.now()) * MS_TO_S || TIME_FRAME_IN_S);
};
...

لاحظ أن السطر الأول في الدالة يحضر مجموعة العلامات الزمنية لعنوان IP المحدد أو يهيئ مصفوفة فارغة إذا كان فارغًا. نقوم في السطر التالي بإضافة العلامة الزمنية الحالية التي التقطت بواسطة الدالة ()new Date إلى المصفوفة.

تأخذ الدالة ()set. ثلاثة وسطاء هي : key و value وTTL، فيعيد الوسيط الأخير تعريف قيمة TTL القياسية عن طريق استبدال قيمة stdTTL في المتغير IPCache، ويستخدم TTL الحالية إذا كان عنوان IP موجودًا في الذاكرة المؤقتة، عدا عن ذلك تُحَدد قيمة TTL من المتغير TIME_FRAME_IN_S.

تُحسَب قيمة TTL لزوج مفتاح-قيمة الحالي عن طريق طرح قيمة العلامة الزمنية الحالية من العلامة الزمنية لانتهاء الصلاحية، وتُحَول النتيجة إلى ثواني ثم تُمَرر إلى حقل الوسيط الثالث في الدالة ()set..

تقبل الدالة ()getTtl. مفتاحًا وعنوان IP كوسطاء وترجع زمن TTL للزوج مفتاح-قيمة كعلامة زمنية، وفي حال عدم وجود عنوان IP في الذاكرة المؤقتة، تُرجِع undefined وتستخدم القيمة الاحتياطية في المتغير TIME_FRAME_IN_S.

اقتباس

ملاحظة: ستحتاج التحويل من صيغة الميللي ثانية إلى صيغة الثواني، إذ أن لغة جافاسكربت JavaScript تستخدم العلامات الزمنية بصيغة الميللي ثانية، أما وحدة node-cache فتستخدم الثواني.

أضف الأسطر التالية في الدالة الوسيطة ipMiddleware بعد تعليمة if (isIp.v6(clientIP))‎ لحساب عدد الطلبات في الثانية من عنوان IP الذي يطلب التطبيق:

...
    updateCache(clientIP);
    const IPArray = IPCache.get(clientIP);
    if (IPArray.length > 1) {
        const rps = IPArray.length / ((IPArray[IPArray.length - 1] - IPArray[0]) * MS_TO_S);
        if (rps > RPS_LIMIT) {
            console.log('You are hitting limit', clientIP);
        }
    }
...

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

بما أننا اسندنا القيمة false إلى الخاصية deleteOnExpire في المتغير IPCache، علينا الآن التعامل يدويُا مع الحدث expired، فتوفر وحدة node-cache دالة استدعاء تُشَغل الحدث expired.

أضف الأسطر التالية بعد المتغير IPCache:

...
IPCache.on('expired', (key, value) => {
    if (new Date() - value[value.length - 1] > TIME_FRAME_IN_MS) {
        IPCache.del(key);
    }
});
...

تقبل دالة رد النداء()on. مفتاح key وقيمة value العنصر منتهي الصلاحية كوسطاء، وتكون value عبارة عن مصفوفة علامات زمنية للطلبات مخزنة في الذاكرة المؤقتة.

يتحقق السطر المحدد الثاني من العنصر الأخير في مصفوفة القيم بمقارنته مع المتغيرTIME_FRAME_IN_S، إذ يطرح آخر عنصر في مصفوفة القيم value من الدالة new Date()‎ (الوقت الحالي)، فإذا كانت النتيجة أصغر من قيمة المتغير TIME_FRAME_IN_S تأخذ الدالة ‎.del()‎ المفتاحkey كوسيط وتحذف العنصر منتهي الصلاحية من ذاكرة التخزين المؤقت.

...
    else {
        const updatedValue = value.filter(function (element) {
            return new Date() - element < TIME_FRAME_IN_MS;
        });
        IPCache.set(key, updatedValue, TIME_FRAME_IN_S - (new Date() - updatedValue[0]) * MS_TO_S);
    }
...

يوفر تابع المصفوفات المحلي filter()‎ في جافاسكريبت دالة استدعاء لترشيح العناصر الموجودة في مصفوفة العلامات الزمنية.

يتحقق السطر الثالث من الشيفرة السابقة من نتيجة طرح العناصر من الدالة new Date()‎ إذا كانت أصغر من المتغير TIME_FRAME_IN_S ويخزن النتيجة في المتغير updatedValue ثم تضاف العناصر التي تمت تصفيتها إلى المتغير updatedValue. يؤدي ذلك إلى تحديث ذاكرة التخزين المؤقت بالعناصر التي تمت تصفيتها في المتغير updatedValue وزمن TTL الجديد.

تحفز قيم TTL التي تطابق العنصر الأول من المتغير updatedValue تشغيل دالة ‎.on('expired')‎عندما تحذف الذاكرة المؤقتة العنصر التالي. وتحسب قيمة زمن TTL الجديد عن طريق حساب الفرق بين المتغير TIME_FRAME_IN_S والوقت منتهي الصلاحية منذ أول علامة زمنية للطلب في المتغير updatedValue.

شَغّل التطبيق من واجهة الطرفية:

node server.js

انتقل إلى العنوان localhost:3000 في متصفح الويب، ولاحظ أن المتصفح سوف يعرض الرسالة: "Successful response"، ثم جرب حَدِث الصفحة عدة مرات حتى تتجاوز قيمة المتغير RPS_LIMIT ولاحظ النتيجة التي ستعرضها الطرفية:

Example app is listening on port 3000
You are hitting limit ::1

ملاحظة: يظهر عنوان localhost IP على الشكل ‎::1، لكن ذلك سيتغير، إذ يلتقط تطبيقك العنوان العام Public IP للمستخدم عند نشره خارج الخادم المحلي localhost.

أصبح بإمكان تطبيقك تتبع طلبات المستخدم وتخزين العلامات الزمنية في ذاكرة التخزين المؤقت.

سنتعلم في الخطوة التالية كيفية استخدام واجهة برمجة تطبيقات Cloudflare لإعداد جدار الحماية Firewall.

إعداد جدار حماية Cloudflare

سنتعلم في هذه الخطوة كيفية إعداد جدار حماية Cloudflare لإيقاف عناوين IP عند الوصول إلى الحد المعين، وكيفية إنشاء متغيرات البيئة environment variables، واستدعاء واجهة برمجة تطبيقات Cloudflare.

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

اقتباس

ملاحظة: يتوفر خيار القوائم Lists في لوحة تحكم الحساب على Cloudflare، وليس من صفحة لوحة تحكم النطاق.

افتح لوحة تحكم النطاق الخاص بك your_domain من الصفحة الرئيسية Home، ثم اضغط على علامة تبويب الجدار الناري Firewall واضغط على قواعد الجدار الناري Firewall Rules ثم على إنشاء قاعدة جديدة Create a Firewall rule وسَمِها باسم تختاره مثل your_rule_name مجازًا.

اختر عنوان المصدر IP Source Address من القائمة المنسدلة، واختر is in list عند خيار المُشغِل Operator، و your_list عند خيار القيمة Value، ثم اضغط على حجب Block من القائمة المنسدلة للخيار Choose an action، واضغط بعدها على زر نشر Deploy.

أنشئ ملفًا بصيغة env. في المجلد الرئيسي للمشروع وأضف عليه الأسطر التالية حتى نتمكن من استدعاء واجهة تطبيقات Cloudflare من تطبيقنا:

ACCOUNT_MAIL=your_cloudflare_login_mail
API_KEY=your_api_key
ACCOUNT_ID=your_account_id
LIST_ID=your_list_id

انتقل إلى قسم الملف الشخصي My Profile في لوحة تحكم Cloudflare، ثم اضغط على علامة تبويب وحدات واجهة التطبيقات API Tokens للحصول على قيمة API_KEY، ثم اضغط على عرض View في قسم Global API Key واكتب كلمة المرور الخاصة بك.

انتقل إلى علامة تبويب الإعدادات Configuration ثم إلى قسم القوائم Lists، واضغط على زر تعديل Edit بجانب القائمة your_list التي أنشأتها. يمكنك الحصول على معرف الحساب ACCOUNT_IDومعرف القائمة LIST_ID من عنوان URL من المتصفح الذي يكون على الصيغة التالية:

https://dash.cloudflare.com/your_account_id/configurations/lists/your_list_id

تنبيه: احرص على أن يكون محتوى الملف env. سريًا وليس متاحًا للجميع، وذلك عن طريق إضافته ضمن ملف gitignore. الذي أنشأناه في الخطوة الأولى.

ثبت حزمة axios و dotenv في الطرفية بواسطة مدير الحزم:

npm i axios dotenv

أضف الأسطر التالية بعد سطر المتغير nodeCache:

...
const axios = require('axios');
require('dotenv').config();
...

يحضر السطر الأول وحدة axios من حزمة axios المثبتة، وسنستخدم هذه الوحدة لإجراء استدعاءات إلى واجهة برمجة تطبيقات Cloudflare. يُعِد السطر الثاني وحدة dotenv ويفَعّل المتغير العام process.env الذي سيعرف قيم ملف env. في ملف server.js.

أضف الأسطر البرمجية التالية إلى تعليمة If الشرطية التالية if (rps > RPS_LIMIT)‎ فوق السطر:console.log('You are hitting limit', clientIP)‎ حتى تتمكن من استدعاء واجهة برمجة تطبيقات Cloudflare:

...
    const url = `https://api.cloudflare.com/client/v4/accounts/${process.env.ACCOUNT_ID}/rules/lists/${process.env.LIST_ID}/items`;
    const body = [{ ip: clientIP, comment: 'your_comment' }];
    const headers = {
        'X-Auth-Email': process.env.ACCOUNT_MAIL,
        'X-Auth-Key': process.env.API_KEY,
        'Content-Type': 'application/json',
    };
    try {
        await axios.post(url, body, { headers });
    } catch (error) {
        console.log(error);
    }
...

أصبح بإمكاننا الآن الاتصال بواجهة برمجة تطبيقات Cloudflare عن طريق العنوان URL لإضافة عنصر، وفي حالتنا سنضيف عنوان IP إلى القائمة your_list، إذ تظهر واجهة برمجة تطبيقات Cloudflare المتغيران ACCOUNT_MAIL و API_KEY في ترويسة الطلب على الشكل X-Auth-Email و X-Auth-Key. أما جسم الطلب فيتألف من عنوان IP الذي سيضاف إلى القائمة وتعليق comment له القيمة your_comment. ضع في الحسبان أنه يمكنك استبدال التعليق comment بالتعليق الذي يحلو لك لتمييز القيمة المدخلة.

يوضع الطلب POST المستدعى على الشكل ()axios.post ضمن الكتلة البرمجية try-catch لمعالجة الأخطاء، إن وجدت، فتحتاج الدالة axios.post إلى الوسطاء التالية: url، body، headers لإنشاء الطلب.

يجب عليك تغيير قيمة المتغير clientIP عند تجريب الطلبات إلى عنوان IP تجريبي مثل: 198.51.100.0/24 لأن Cloudflare لايقبل عنوان الخادم المحلي localhost:

...
let clientIP = '198.51.100.0/24';
...

شغل التطبيق من واجهة الطرفية:

node server.js

انتقل إلى العنوان localhost:3000 في المتصفح وستلاحظ ظهور الرسالة: "Successful response".

حَدِث الصفحة عدة مرات حتى تتجاوز قيمة المتغير RPS_LIMIT ولاحظ النتيجة التي ستعرضها الطرفية:

Example app is listening on port 3000
You are hitting limit ::1

انتقل الآن إلى صفحة لوحة تحكم Cloudflare ثم إلى صفحة القوائم your_list حيث سيظهر عنوان IP الذي أضفناه في القائمة your_list، ثم ستظهر صفحة الجدار الناري بعد إرسال التغييرات إلى GitHub.

اقتباس

ملاحظة: احرص على تغيير قيم المتغير clientIP إلى (requestIP.getClientIp(req قبل إرسال الشيفرة إلى GitHub.

انشر تطبيقك بعد حفظ التعديلات وارفع الشيفرة على GitHub، وبنا أننا فعّلنا خيار النشر التلقائي auto-deploy سيرسل الكود تلقائيًا من GitHub إلى منصة App Platform لنشره.

ستحتاج إلى إضافة ملف env. إلى منصة App Platform في قسم متغيرات بيئة التطبيق App-Level Environment Variables من تبويبة الإعدادات Settings. أضف زوج مفتاح-قيمة إلى ملف env. كي يستطيع تطبيقك الوصول إلى محتوياته من App Platform.

انتقل إلى نطاقك في المتصفح بعد انتهاء النشر وحَدِث الصفحة باستمرار حتى تصل إلى الحد RPS_LIMIT، عندها سيظهر المستعرض صفحة الجدار الناري من Cloudflare:

ستحصل على الرسالة التالية عند الانتقال إلى علامة تبويب سجلات التشغيل الحالية Runtime Logs في لوحة تحكم App Platform:

You are hitting limit your_public_ip

يمكنك التأكد من أن الجدار الناري يحظر عنوان IP المحدد في القائمة your_list فقط، عن طريق الدخول إلى نطاقك your_domain من جهاز أخر أو عبر اتصال VPN، ويمكنك حذف عنوان IP من لوحة تحكم Cloudflare.

قد يتطلب الحصول على رد من الجدار الناري بضع ثوان بسبب الرد المخزن سابقُا في المتصفح.

مبارك! لقد أعددت جدار Cloudflare الناري لحظر عناوين IP عندما يصل المستخدمون إلى حد معدل التراسل عن طريق استدعاء واجهة برمجة تطبيقات Cloudflare.

ختامًا

تعلمنا في هذا المقال كيفية إنشاء مشروع Node.js ونشره على منصة App Platform من DigitalOcean وتوجيهه للاتصال بنطاقك Cloudflare، وطبقنا إجراء حماية للنطاق من زيادة حد معدل التراسل عن طريق إعداد الجدار الناري في Cloudflare.

يمكنك، فيما بعد، تعديل قاعدة الجدار الناري لإظهار تحدٍ JS Challenge أو رمز تحقق كابتشا CAPTCHA بدلاً من حظر المستخدم، اطلع على مستندات Cloudflare لمزيد من التفاصيل حول ذلك.

وللحصول على المساعدة والدعم يمكنك إضافة سؤالك في قسم الأسئلة والأجوبة في أكاديمية حسوب.

ترجمة- وبتصرف للمقال How To Build a Rate Limiter With Node.js on App Platform لصاحبه Abel Mathew

اقرأ أيضًا

• بناء تطبيق Node.js باستخدام Docker
• دمج قاعدة البيانات MongoDB في تطبيقك Node
• إدارة المستخدمين في تطبيق Node.js باستعمال قواعد بيانات MongoDB ومكتبة Mongoose
• حفظ بيانات تطبيقات Node.js في قاعدة بيانات MongoDB
• اختبار الواجهة الخلفية لتطبيقات Node.js عبر مكتبة Jest

اقتباس

لا أعلم بعد النبوة أفضل من بث العلم.

ـــ عبد الله بن المبارك.

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

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

التصميم

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

يهيَّأ التطبيق ليعرض الكلمات المقترحة وتعليقاتها عرضًا حيًا، وكلما أرسل أحد كلمةً جديدةً في مكان ما أو أضاف تعليقًا فيجب على كل من تكون الصفحة مفتوحة عنده رؤية ذلك الحدث، وهنا محل التحدي إذ لا توجد طريقة يفتح بها الخادم اتصالًا مع عميل ولا توجد طريقة مناسبة لنعرف مَن من العملاء ينظرون الآن إلى الموقع، ويسمى حل تلك المشكلة بالاستطلاع المفتوح long polling وهو أحد بواعث تصميم بيئة Node من البداية.

الاستطلاع المفتوح

نحتاج إلى اتصال بين العميل والخادم كي يستطيع الخادم إخبار العميل مباشرةً بتغير شيء ما، لكن لا تقبل متصفحات الويب الاتصالات عادةً، كما أنّ موجِّهات الانترنت routers تحجب عادةً مثل تلك الاتصالات عن العملاء، لذا لن نستطيع جعل الخادم يبدأ ذلك الاتصال، لكن نستطيع تهيئة الأمر كي يفتح العميل الاتصال ويحتفظ به لفترة كي يستطيع الخادم استخدامه من أجل إرسال معلومات عند الحاجة، غير أنّ طلب HTTP يسمح بتدفق معلومات بسيطة مثل إرسال العميل لطلب ما ورد الخادم عليه باستجابة لذلك الطلب وحسب.

أما إذا أردنا أكثر من ذلك فثَم تقنية اسمها WebSockets تدعمها أغلب المتصفحات الحديثة وتسهل فتح الاتصالات من أجل تبادل البيانات عشوائي، غير أنها صعبة قليلًا في الاستفادة منها لحالتنا، والبديل الذي سنستخدِمه في هذا المقال سيكون تقنيةً أبسط وهي الاستطلاع المفتوح، حيث يطلب العميل من الخادم معلومات جديدة باستمرار باستخدام طلبات HTTP العادية، ويماطل الخادم في الاستجابة لتلك الطلبات إذا لم يكن ثمة شيء جديد لإبلاغه، وطالما أنّ العميل يضمن وجود طلب استطلاع وجس مفتوح دائمًا، فسيستقبل معلومات من الخادم بسرعة بعد توفرها، فإذا كان تطبيق مشاركة المهارات مفتوحًا لدى فاطمة في متصفحها، فسيكون ذلك المتصفح قد أنشأ طلبًا من أجل التحديثات وسيكون منتظرًا استجابةً لذلك الطلب، فإذا أرسلت إيمان كلمةً عن قيادة الدراجة هبوطًا على تل شديد الانحدار، فسيلاحظ الخادم انتظار فاطمة تحديثات، ويرسل استجابةً تحتوي على الكلمة الجديدة إلى طلبها المنتظِر، وسيستلم متصفح فاطمة تلك البيانات ويحدِّث الشاشة ليعرض الكلمة.

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

واجهة HTTP

ينبغي النظر أولًا قبل تصميم الخادم أو العميل إلى النقطة التي يتلاقى فيها كل منهما، وهي واجهة HTTP التي يتواصلان من خلالها، حيث سنستخدم JSON على أساس صيغة لطلبنا وعلى أساس متن للاستجابة أيضًا، كما سنستفيد من توابع HTTP وترويساته كما في خادم الملفات من المقال السابق المشار إليه سلفًا، وبما أنّ الواجهة تتمحور حول مسار ‎/talks، فستُستخدَم المسارات التي لا تبدأ بـ ‎/talks لخدمة الملفات الساكنة، وهي شيفرة HTML وجافاسكربت لنظام جانب العميل، فإذا أرسلنا طلب GET إلى /talks فسيعيد مستند JSON يشبه ما يلي:

[{"title": "Unituning",
  "presenter": "Jamal",
  "summary": "Modifying your cycle for extra style",
  "comments": []}]

تُنشأ الكلمة الجديدة بإنشاء طلب PUT إلى رابط مثل ‎/talks/Unituning، حيث يكون الجزء الذي بعد الشرطة الثانية هو عنوان الكلمة، ويجب احتواء متن طلب PUT على كائن JSON يستخدِم الخاصيتين presenter وsummary، وبما أنّ عناوين الكلمات تحتوي على مسافات ومحارف قد لا تظهر كما يجب لها في الرابط، فيجب ترميز سلاسل العناوين النصية بدالة encodeURIComponent عند بناء مثل تلك الروابط.

console.log("/talks/" + encodeURIComponent("How to Idle"));
// → /talks/How%20to%20Idle

قد يبدو طلب إنشاء كلمة عن الوقوف بالدراجة كما يلي:

PUT /talks/How%20to%20Idle HTTP/1.1
Content-Type: application/json
Content-Length: 92

{"presenter": "Hasan",
 "summary": "Standing still on a unicycle"}

تدعم مثل تلك الروابط طلبات GET لجلب تمثيل JSON لكلمة ما وطلبات DELETE لحذف الكلمة، كما تضاف التعليقات إلى الكلمة باستخدام طلب POST إلى رابط مثل ‎/talks/Unituning/comments مع متن JSON يحتوي على الخاصيتين author وmessage.

POST /talks/Unituning/comments HTTP/1.1
Content-Type: application/json
Content-Length: 72

{"author": "Iman",
 "message": "Will you talk about raising a cycle?"}

قد تحتوي طلبات GET إلى ‎/talks على ترويسات إضافية تخبر الخادم بتأخير الإجابة إذا لم تتوفر معلومات جديدة، وذلك من أجل دعم الاستطلاع المفتوح، كما سنستخدِم زوجًا من الترويسات صُممتا أساسًا من أجل إدارة التخزين المؤقت وهما ETag وIf-None-Match، وقد تدرِج الخوادم ترويسة ETag -التي تشير إلى وسم الكتلة Entity Tag- في الاستجابة، بحيث تكون قيمتها سلسلةً نصيةً تعرِّف الإصدار الحالي للمورِد، وقد تنشئ العملاء طلبًا إضافيًا عندما تطلب هذا المورد مرةً ثانيةً من خلال إدراج ترويسة If-None-Match التي تحمل قيمتها السلسلة نفسها؛ أما إذا لم يتغير المورد، فسيستجيب الخادم برمز الحالة 304 والذي يعني "غير معدَّل not modified"، ليخبر العميل أنّ إصداره المخزَّن لا زال هو الإصدار الحالي؛ أما إذا لم يطابق الوسم، فسيستجيب الاستجابة العادية.

نحتاج إلى مثل ذلك النظام لأننا نريد تمكين العميل من إخبار الخادم بإصدار قائمة الكلمات التي لديه، وألا يستجيب الخادم إلا عند تغير تلك القائمة، لكن ينبغي على الخادم تأخير الإجابة وعدم الإعادة نهائيًا إلا عند توفر شيء جديد أو مرور مهلة زمنية محددة بدلًا من إعادة 304 مباشرةً، وعليه فمن أجل تمييز طلبات الاستطلاع المفتوح عن الطلبات الشرطية العادية، فإننا نعطيها ترويسةً أخرى هي Prefer: wait=90 التي تخبر الخادم باستعداد العميل لانتظار الاستجابة مدةً قدرها 90 ثانية، كما سيحتفظ الخادم برقم إصدار version number يحدِّثه في كل مرة تتغير فيها كلمة ما، وسيستخدم ذلك على أساس قيمة لوسم ETag، ويمكن للعملاء إنشاء طلبات مثل هذا ليتم إشعارها عند حدوث تغيير في الكلمة:

GET /talks HTTP/1.1
If-None-Match: "4"
Prefer: wait=90

(time passes)

HTTP/1.1 200 OK
Content-Type: application/json
ETag: "5"
Content-Length: 295

[....]

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

الخادم

لنبدأ ببناء جانب الخادم من البرنامج، حيث ستعمل الشيفرة في هذا القسم على Node.js.

التوجيه Routing

سيستخدم خادمنا createServer من أجل بدء خادم HTTP، ويجب علينا التفريق في الدالة التي تعالج طلبًا جديدًا بين أنواع الطلبات المختلفة التي ندعمها وفقًا للتابع والمسار، وصحيح أنه يمكن تنفيذ ذلك بسلسلة طويلة من تعليمات if، إلا أنّ طريقة التوجيه أفضل، فالموجّه هو مكون يساعد في إرسال طلب إلى الدالة التي تستطيع معالجته، فنستطيع إخباره أنّ طلبات PUT مثلًا التي يطابق مسارها التعبير النمطي ‎/^\/talks\/([^\/]+)$/‎ -يشير إلى ‎/talks/‎ متبوعًا بعنوان الكلمة-، يمكن معالجتها بدالة ما، كما يساعد على استخراج أجزاء مفيدة من المسار -عنوان الكلمة في حالتنا- مغلَّفًا بين أقواس في التعبير النمطي ثم يمررها إلى الدالة المعالجة.

هناك عدة حزم موجهات جيدة على NPM، لكننا سنكتب واحدةً بأنفسنا لتوضيح الفكرة، وتوضِّح الشيفرة التالية router.js الذي سنطلبه من وحدة الخادم الخاص بنا عن طريق require لاحقًا:

const {parse} = require("url");

module.exports = class Router {
  constructor() {
    this.routes = [];
  }
  add(method, url, handler) {
    this.routes.push({method, url, handler});
  }
  resolve(context, request) {
    let path = parse(request.url).pathname;

    for (let {method, url, handler} of this.routes) {
      let match = url.exec(path);
      if (!match || request.method != method) continue;
      let urlParts = match.slice(1).map(decodeURIComponent);
      return handler(context, ...urlParts, request);
    }
    return null;
  }
};

تصدِّر الوحدة صنف Router، كما يسمح كائن الموجّه بتسجيل معالِجات جديدة باستخدام التابع add، ويمكن حل الطلبات باستخدام التابع resolve الخاص به، حيث سيعيد هذا التابع استجابةً عند العثور على معالج، وإذا لم يعثر فسيعيد قيمةً غير معرَّفة null، ويجرب طريقًا واحدًا في كل مرة بالترتيب الذي عرِّفَت به تلك الطرق إلى أن يعثر على تطابق، كما تُستدعَى الدوال المعالجة بقيمة context التي ستكون نسخة الخادم في حالتنا وسلاسل المطابقة لأيّ مجموعة تعرّفها في تعبيرنا النمطي وكائن الطلب، كما يجب فك تشفير روابط السلاسل النصية بما أنّ الرابط الخام قد يحتوي على رموز من تنسيق ‎%20.

تقديم الملفات

إذا لم يطابق الطلب أي نوع معرّف في موجهنا فيجب على الخادم تفسير ذلك على أنه طلب لملف في مجلد public، ومن الممكن هنا استخدام خادم الملفات المعرَّف في المقال السابق لتقديم مثل تلك الملفات، لكننا لا نحتاج ولا نريد دعم طلبات PUT أو DELETE على الملفات، ونرغب أن يكون لدينا ميزات مثل دعم التخزين، وعليه فسنستخدم خادم ملفات ساكنة مجرَّبًا من NPM وليكن ecstatic مثلًا، رغم أنه ليس الوحيد على NPM ولكنه يعمل جيدًا ومناسب لأغراضنا.

تصدِّر حزمة ecstatic دالةً يمكن استدعاؤها مع كائن تهيئة configuration object لإنتاج دالة معالجة طلبات، وسنستخدِم الخيار root لنخبر الخادم بالمكان الذي يجب أعليه البحث فيه عن الملفات، كما تقبل الدالة المعالِجة المعاملَين request وresponse ويمكن تمريرهما مباشرةً إلى createServer لإنشاء خادم لا يقدم لنا إلا الملفات فقط، كما نريد التحقق أولًا من الطلبات التي يجب معالجتها معالجةً خاصةً، لذا نغلفها في دالة أخرى.

const {createServer} = require("http");
const Router = require("./router");
const ecstatic = require("ecstatic");

const router = new Router();
const defaultHeaders = {"Content-Type": "text/plain"};

class SkillShareServer {
  constructor(talks) {
    this.talks = talks;
    this.version = 0;
    this.waiting = [];

    let fileServer = ecstatic({root: "./public"});
    this.server = createServer((request, response) => {
      let resolved = router.resolve(this, request);
      if (resolved) {
        resolved.catch(error => {
          if (error.status != null) return error;
          return {body: String(error), status: 500};
        }).then(({body,
                  status = 200,
                  headers = defaultHeaders}) => {
          response.writeHead(status, headers);
          response.end(body);
        });
      } else {
        fileServer(request, response);
      }
    });
  }
  start(port) {
    this.server.listen(port);
  }
  stop() {
    this.server.close();
  }
}

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

الكلمات على أساس موارد

تخزَّن الكلمات المقترحة في الخاصية talks للخادم، وهو كائن تكون أسماء خصائصه عناوين الكلمات، كما ستُكشف على أساس موارد HTTP تحت ‎/talks/[title]‎، لذا نحتاج إلى إضافة معالجات إلى الموجه الخاص بنا تستخدِم التوابع المختلفة التي تستطيع العملاء استخدامها كي تعمل معها، كما يجب على معالج طلبات GET التي تطلب كلمة بعينها البحث عن تلك الكلمة، ويستجيب ببيانات JSON لها أو باستجابة خطأ 404.

const talkPath = /^\/talks\/([^\/]+)$/;

router.add("GET", talkPath, async (server, title) => {
  if (title in server.talks) {
    return {body: JSON.stringify(server.talks[title]),
            headers: {"Content-Type": "application/json"}};
  } else {
    return {status: 404, body: `No talk '${title}' found`};
  }
});

تُحذَف الكلمة بحذفها من الكائن talks.

router.add("DELETE", talkPath, async (server, title) => {
  if (title in server.talks) {
    delete server.talks[title];
    server.updated();
  }
  return {status: 204};
});

يرسل التابع updated -الذي سنعرِّفه لاحقًا- إشعارات إلى طلبات الاستطلاع المفتوح المنتظرة بشأن التغيير، ولجلب محتوى متن الطلب فإننا نعرِّف دالةً تدعى readStream تقرأ كل المحتوى من بث قابل للقراءة وتعيد وعدًا يُحل إلى سلسلة نصية.

function readStream(stream) {
  return new Promise((resolve, reject) => {
    let data = "";
    stream.on("error", reject);
    stream.on("data", chunk => data += chunk.toString());
    stream.on("end", () => resolve(data));
  });
}

أحد المعالِجات التي تحتاج إلى قراءة متون الطلبات هو PUT المستخدَم في إنشاء كلمات جديدة، ويجب عليه التحقق من إذا كانت البيانات المعطاة لها الخصائص presenter وsummary والتي تكون سلاسل نصية، فقد تكون أيّ بيانات قادمة من خارج النظام غير منطقية، ولا نريد إفساد نموذج بياناتنا الداخلية أو تعطيله إذا أتت طلبات سيئة bad requests، وإذا بدت البيانات صالحةً، فسيخزِّن المعالِج كائنًا يمثِّل الكلمة الجديدة في كائن talks، وهذا سيكتب فوق كلمة موجودة سلفًا في العنوان نفسه ويستدعي updated مرةً أخرى.

router.add("PUT", talkPath,
           async (server, title, request) => {
  let requestBody = await readStream(request);
  let talk;
  try { talk = JSON.parse(requestBody); }
  catch (_) { return {status: 400, body: "Invalid JSON"}; }

  if (!talk ||
      typeof talk.presenter != "string" ||
      typeof talk.summary != "string") {
    return {status: 400, body: "Bad talk data"};
  }
  server.talks[title] = {title,
                         presenter: talk.presenter,
                         summary: talk.summary,
                         comments: []};
  server.updated();
  return {status: 204};
});

تعمل إضافة تعليق إلى كلمة ما بصورة مشابهة، إذ نستخدِم readStream لنحصل على محتوى الطلب ونتحقق من البيانات الناتجة ونخزِّنها على هيئة تعليق إذا كانت صالحةً.

router.add("POST", /^\/talks\/([^\/]+)\/comments$/,
           async (server, title, request) => {
  let requestBody = await readStream(request);
  let comment;
  try { comment = JSON.parse(requestBody); }
  catch (_) { return {status: 400, body: "Invalid JSON"}; }

  if (!comment ||
      typeof comment.author != "string" ||
      typeof comment.message != "string") {
    return {status: 400, body: "Bad comment data"};
  } else if (title in server.talks) {
    server.talks[title].comments.push(comment);
    server.updated();
    return {status: 204};
  } else {
    return {status: 404, body: `No talk '${title}' found`};
  }
});