لماذا بحق الجحيم سأستخدم Node.js؟ برنامج تعليمي لكل حالة على حدة

مقدمة

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

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

كما تنص ويكيبيديا: "Node.js عبارة عن تجميع مجمع لمحرك Google V8 JavaScript وطبقة تجريد النظام الأساسي libuv والمكتبة الأساسية ، والتي تتم كتابتها بشكل أساسي في JavaScript." علاوة على ذلك ، تجدر الإشارة إلى أن Ryan Dahl ، منشئ Node.js ، كان يهدف إلى إنشاء مواقع ويب في الوقت الفعلي مع إمكانية الدفع ، "مستوحاة من تطبيقات مثل Gmail". في Node.js ، قدم للمطورين أداة للعمل في نموذج الإدخال / الإخراج غير المحظور والمدفوع بالحدث.

بجملة واحدة: يتألق Node.js في تطبيقات الويب في الوقت الفعلي التي تستخدم تقنية الدفع عبر مآخذ الويب. ما الشيء الثوري في ذلك؟ حسنًا ، بعد أكثر من 20 عامًا من استخدام الويب عديم الجنسية استنادًا إلى نموذج الاستجابة للطلب عديم الحالة ، أصبح لدينا أخيرًا تطبيقات ويب ذات اتصالات ثنائية الاتجاه في الوقت الفعلي ، حيث يمكن للعميل والخادم بدء الاتصال ، مما يسمح لهم بتبادل البيانات بحرية . هذا في تناقض صارخ مع نموذج استجابة الويب النموذجي ، حيث يبدأ العميل دائمًا الاتصال. بالإضافة إلى ذلك ، يعتمد الأمر كله على مكدس الويب المفتوح (HTML و CSS و JS) الذي يعمل عبر المنفذ القياسي 80.

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

مع كل مزاياها ، تلعب Node.js الآن دورًا مهمًا في مجموعة التكنولوجيا للعديد من الشركات البارزة التي تعتمد على مزاياها الفريدة. قامت مؤسسة Node.js بتوحيد أفضل الأفكار حول سبب وجوب اعتبار المؤسسات لـ Node.js في عرض تقديمي قصير يمكن العثور عليه في صفحة دراسات الحالة لمؤسسة Node.js.

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

كيف يعمل؟

الفكرة الرئيسية لـ Node.js: استخدام الإدخال / الإخراج غير المحظور والمدفوع بالأحداث لتبقى خفيفة الوزن وفعالة في مواجهة تطبيقات الوقت الفعلي كثيفة البيانات التي تعمل عبر الأجهزة الموزعة.

هذا هو الفم.

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

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

عملية حسابية سريعة: بافتراض أن كل مؤشر ترابط يحتوي على ذاكرة 2 ميجابايت مرفقة به ، فإن التشغيل على نظام به ذاكرة وصول عشوائي 8 جيجابايت يضعنا في حد أقصى نظريًا يصل إلى 4000 اتصال متزامن (الحسابات مأخوذة من مقال مايكل أبرنيثي "ما هي العقدة فقط .js؟ "، المنشور على IBM developerWorks في عام 2011 ؛ لسوء الحظ ، لم تعد المقالة متوفرة) ، بالإضافة إلى تكلفة تبديل السياق بين سلاسل الرسائل. هذا هو السيناريو الذي تتعامل معه عادةً في تقنيات خدمة الويب التقليدية. من خلال تجنب كل ذلك ، يحقق Node.js مستويات قابلية التوسع لأكثر من مليون اتصال متزامن وأكثر من 600 ألف اتصال بمقابس ويب متزامنة.

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

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

NPM: مدير حزمة العقدة

عند مناقشة Node.js ، هناك شيء واحد لا يجب حذفه بالتأكيد وهو الدعم المدمج لإدارة الحزم باستخدام NPM ، وهي أداة تأتي افتراضيًا مع كل تثبيت Node.js. تشبه فكرة وحدات NPM تمامًا فكرة Ruby Gems : مجموعة من المكونات المتاحة للجمهور والقابلة لإعادة الاستخدام والمتاحة من خلال التثبيت السهل عبر مستودع عبر الإنترنت ، مع إدارة الإصدار والتبعيات.

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

بعض وحدات npm الأكثر فائدة اليوم هي:

• Express - Express.js - أو ببساطة Express - إطار عمل لتطوير الويب مستوحى من سيناترا لـ Node.js ، والمعيار الواقعي لمعظم تطبيقات Node.js الموجودة حاليًا.
• hapi - إطار معياري جدًا وبسيط في الاستخدام يتمحور حول التكوين لبناء تطبيقات الويب والخدمات
• connect - Connect هو إطار عمل خادم HTTP قابل للتوسيع لـ Node.js ، يوفر مجموعة من "المكونات الإضافية" عالية الأداء والمعروفة باسم البرامج الوسيطة ؛ يعمل كأساس أساسي لـ Express.
• socket.io و sockjs - مكون من جانب الخادم لاثنين من أكثر مكونات مآخذ الويب شيوعًا الموجودة اليوم.
• الصلصال (المعروف سابقًا باسم Jade ) - أحد محركات القوالب الشهيرة ، المستوحى من HAML ، وهو محرك افتراضي في Express.js.
• mongodb و mongojs - أغلفة MongoDB لتوفير واجهة برمجة التطبيقات لقواعد بيانات كائن MongoDB في Node.js.
• redis - مكتبة عملاء Redis.
• لوداش (شرطة سفلية ، lazy.js) - حزام الأداة المساعدة JavaScript. بدأ Underscore اللعبة ، ولكن تم الإطاحة به من قبل أحد نظرائه ، ويرجع ذلك أساسًا إلى الأداء الأفضل والتنفيذ المعياري.
• إلى الأبد - ربما الأداة الأكثر شيوعًا لضمان تشغيل برنامج نصي للعقدة بشكل مستمر. يحافظ على عملية إنتاج Node.js في مواجهة أي إخفاقات غير متوقعة.
• بلوبيرد - وعود مميزة كاملة / تنفيذ A + مع أداء جيد بشكل استثنائي
• لحظة - مكتبة تاريخ JavaScript لتحليل التواريخ والتحقق منها ومعالجتها وتنسيقها.

والقائمة تطول. هناك الكثير من الحزم المفيدة حقًا المتاحة للجميع (لا توجد إهانة لتلك التي حذفتها هنا).

أمثلة على مكان استخدام Node.js

دردشة

الدردشة هي التطبيق الأكثر شيوعًا في الوقت الفعلي متعدد المستخدمين. من IRC (مرة أخرى في اليوم) ، من خلال العديد من البروتوكولات المفتوحة والملكية التي تعمل على منافذ غير قياسية ، إلى القدرة على تنفيذ كل شيء اليوم في Node.js مع مآخذ ويب تعمل عبر المنفذ القياسي 80.

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

دعنا نحاول تصوير كيف يعمل.

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

من جانب الخادم ، لدينا تطبيق Express.js بسيط ينفذ شيئين:

1. معالج GET / request الذي يخدم صفحة الويب التي تحتوي على كل من لوحة الرسائل وزر "إرسال" لتهيئة إدخال رسالة جديدة ، و
2. خادم websocket الذي يستمع للرسائل الجديدة المنبعثة من عملاء websocket.

من جانب العميل ، لدينا صفحة HTML مع إعداد معالجات ، واحدة لحدث النقر على الزر "إرسال" ، والتي تلتقط رسالة الإدخال وترسلها إلى أسفل المقبس ، وأخرى تستمع إلى الرسائل الواردة الجديدة على عميل websockets (على سبيل المثال ، الرسائل المرسلة من قبل مستخدمين آخرين ، والتي يريد الخادم الآن أن يعرضها العميل).

عندما ينشر أحد العملاء رسالة ، فإليك ما يحدث:

1. يمسك المتصفح زر "إرسال" بالنقر فوق معالج جافا سكريبت ، ويلتقط القيمة من حقل الإدخال (أي نص الرسالة) ، ويبعث رسالة websocket باستخدام عميل websocket المتصل بخادمنا (تمت تهيئته عند تهيئة صفحة الويب).
2. يتلقى المكون من جانب الخادم لاتصال websocket الرسالة ويعيد توجيهها إلى جميع العملاء الآخرين المتصلين باستخدام طريقة البث.
3. يتلقى جميع العملاء الرسالة الجديدة كرسالة دفع عبر مكون من جانب العميل websockets يعمل داخل صفحة الويب. ثم يلتقطون محتوى الرسالة ويحدّثون صفحة الويب في مكانها عن طريق إلحاق الرسالة الجديدة باللوحة.

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

API في الجزء العلوي من قاعدة بيانات كائن

على الرغم من أن Node.js يتألق حقًا مع تطبيقات الوقت الفعلي ، إلا أنه مناسب تمامًا لعرض البيانات من قواعد بيانات الكائن (مثل MongoDB). تسمح بيانات JSON المخزنة لـ Node.js بالعمل بدون عدم تطابق المعاوقة وتحويل البيانات.

على سبيل المثال ، إذا كنت تستخدم ريلز ، فيمكنك التحويل من JSON إلى نماذج ثنائية ، ثم تعرضها مرة أخرى كـ JSON عبر HTTP عندما يتم استهلاك البيانات بواسطة Backbone.js أو Angular.js وما إلى ذلك ، أو حتى jQuery AJAX العادي المكالمات. باستخدام Node.js ، يمكنك ببساطة عرض كائنات JSON باستخدام واجهة برمجة تطبيقات REST ليستخدمها العميل. بالإضافة إلى ذلك ، لا داعي للقلق بشأن التحويل بين JSON وأي شيء آخر عند القراءة أو الكتابة من قاعدة البيانات الخاصة بك (إذا كنت تستخدم MongoDB). باختصار ، يمكنك تجنب الحاجة إلى تحويلات متعددة باستخدام تنسيق تسلسل بيانات موحد عبر العميل والخادم وقاعدة البيانات.

المدخلات QUEUED

إذا كنت تتلقى قدرًا كبيرًا من البيانات المتزامنة ، يمكن أن تصبح قاعدة البيانات الخاصة بك عنق زجاجة. كما هو موضح أعلاه ، يمكن لـ Node.js التعامل بسهولة مع الاتصالات المتزامنة بنفسها. ولكن نظرًا لأن الوصول إلى قاعدة البيانات عملية حظر (في هذه الحالة) ، فإننا نواجه مشكلة. الحل هو الاعتراف بسلوك العميل قبل أن تتم كتابة البيانات بالفعل في قاعدة البيانات.

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

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

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

دفق البيانات

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

الوكيل

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

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

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

السمسرة - لوحة معلومات تاجر الأسهم

دعنا نعود إلى مستوى التطبيق. مثال آخر حيث تهيمن برامج سطح المكتب ، ولكن يمكن استبدالها بسهولة بحل ويب في الوقت الفعلي ، هو برنامج تداول الوسطاء ، المستخدم لتتبع أسعار الأسهم ، وإجراء الحسابات / التحليل الفني ، وإنشاء الرسوم البيانية / الرسوم البيانية.

من شأن التبديل إلى حل قائم على الويب في الوقت الفعلي أن يسمح للوسطاء بالتبديل بسهولة بين محطات العمل أو أماكن العمل. قريباً ، قد نبدأ في رؤيتهم على الشاطئ في فلوريدا .. أو إيبيزا .. أو بالي.

التطبيق لوحة التحكم

حالة استخدام شائعة أخرى تتناسب فيها Node-with-web-sockets تمامًا: تتبع زوار موقع الويب وتصور تفاعلاتهم في الوقت الفعلي.

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

تخيل كيف يمكنك تحسين عملك إذا كنت تعرف ما يفعله زوارك في الوقت الفعلي - إذا كان بإمكانك تصور تفاعلاتهم. مع مقابس الوقت الفعلي ثنائية الاتجاه لـ Node.js ، يمكنك الآن.

لوحة معلومات مراقبة النظام

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

يمكن الإبلاغ عن حالات الخدمات الداخلية (داخل الشركة) والعامة بشكل مباشر وفي الوقت الفعلي باستخدام هذه التقنية. ادفع بهذه الفكرة إلى أبعد من ذلك وحاول تخيل تطبيقات مراقبة مركز عمليات الشبكة (NOC) في مشغل اتصالات أو مزود خدمة سحابية / شبكة / استضافة أو بعض المؤسسات المالية ، تعمل جميعها على مكدس الويب المفتوح المدعوم من Node.js و websockets بدلاً من Java و / أو تطبيقات Java الصغيرة.

أين يمكن استخدام Node.js

تطبيقات الويب من جانب الخادم

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

الايجابيات:

• إذا لم يكن تطبيقك يحتوي على أي حساب مكثف لوحدة المعالجة المركزية ، فيمكنك بناؤه في Javascript من أعلى إلى أسفل ، حتى وصولاً إلى مستوى قاعدة البيانات إذا كنت تستخدم تخزين JSON كائنات DB مثل MongoDB. هذا يسهل عملية التطوير (بما في ذلك التوظيف) بشكل كبير.
• تتلقى برامج الزحف استجابة HTML كاملة العرض ، وهي أكثر ملاءمة لكبار المسئولين الاقتصاديين من ، على سبيل المثال ، تطبيق صفحة واحدة أو تطبيق Websockets الذي يتم تشغيله أعلى Node.js.

سلبيات:

• ستؤدي أي عملية حسابية مكثفة لوحدة المعالجة المركزية إلى حظر استجابة Node.js ، لذا فإن النظام الأساسي المترابط هو نهج أفضل. بدلاً من ذلك ، يمكنك محاولة توسيع نطاق الحساب [*].
• لا يزال استخدام Node.js مع قاعدة بيانات علائقية يمثل مشكلة كبيرة (انظر أدناه لمزيد من التفاصيل). افعل لنفسك معروفًا واختر أي بيئة أخرى مثل Rails أو Django أو ASP.Net MVC إذا كنت تحاول إجراء عمليات علائقية.

حيث لا ينبغي استخدام Node.js

تطبيق الويب من جانب الخادم مع قاعدة بيانات متعلقة بالخادم

بمقارنة Node.js مع Express.js مقابل Ruby on Rails ، على سبيل المثال ، كان هناك قرار واضح لصالح الأخير عندما يتعلق الأمر بالوصول إلى قواعد البيانات العلائقية مثل PostgreSQL و MySQL و Microsoft SQL Server.

كانت أدوات قاعدة البيانات العلائقية لـ Node.js لا تزال في مراحلها الأولى. من ناحية أخرى ، توفر ريلز تلقائيًا إعداد الوصول إلى البيانات فور إخراجها من الصندوق مع أدوات دعم عمليات ترحيل مخطط قاعدة البيانات وغيرها من الأحجار الكريمة (يقصد التورية). تمتلك ريلز وإطاراتها النظيرة تطبيقات ناضجة ومثبتة لطبقة الوصول إلى بيانات Active Record أو Data Mapper. [*]

لكن الأمور تغيرت. لقد قطعت Sequelize و TypeORM و Bookshelf شوطًا طويلاً نحو أن تصبح حلول إدارة العمليات الإدارية ناضجة. قد يكون من المفيد أيضًا التحقق من الانضمام إلى Monster إذا كنت تبحث عن إنشاء SQL من استعلامات GraphQL.

المعالجة / المعالجة الثقيلة من جانب الخادم

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

كما ذكرنا سابقًا ، فإن Node.js هو خيوط أحادية ويستخدم فقط نواة واحدة لوحدة المعالجة المركزية. عندما يتعلق الأمر بإضافة التزامن على خادم متعدد النواة ، هناك بعض الأعمال التي يقوم بها فريق Node core في شكل وحدة الكتلة [المرجع: http://nodejs.org/api/cluster.html]. يمكنك أيضًا تشغيل العديد من مثيلات خادم Node.js بسهولة كبيرة خلف وكيل عكسي عبر nginx.

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

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

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

خاتمة

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

تذكر: لم يتم إنشاء Node.js مطلقًا لحل مشكلة قياس الحساب. تم إنشاؤه لحل مشكلة تحجيم الإدخال / الإخراج ، والتي تعمل بشكل جيد حقًا.

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