جمع مؤلف المادة ، التي ننشر ترجمتها ، 19 فكرة قد تكون مفيدة لمطوري Node.js الذين يرغبون في تحسين مستواهم المهني في عام 2019. عالم JavaScript ضخم ، لذا فإن إتقان كل شيء سيتم مناقشته هنا هو ببساطة غير واقعي. من غير المحتمل أن يكون هناك شخص يمتلك كل هذا بشكل مثالي. ومع ذلك ، قد يكون شيء ما في هذا الاستعراض مفيدًا لك.
1. فكر في الكتابة. إيلاء الاهتمام ل TypeScript
لقد ثبت أن البرمجة في جافا سكريبت ، باستخدام طريقة الكتابة المستخدمة فيها ، تؤدي إلى انخفاض في إنتاجية العمال وظهور الأخطاء. هذا لا يعني أنه يجب عليك السعي للتأكد من أن جميع الشفرات مكتوبة بقوة. بدلاً من ذلك ، نحن نتحدث عن حقيقة أنه سيكون من الجيد ، عند التطوير في JavaScript ، اختيار طريقة معينة للتعامل مع الأنواع والالتزام بها. تختلف هذه الأساليب ، من بين أمور أخرى ، عن مستوى القيود المرتبطة بأنواع البيانات المفروضة على الكود. على سبيل المثال ، يمكن أن يكون شيئًا بسيطًا جدًا ، مثل تنظيم الشيكات باستخدام
حزمة jsonschema (أو
joi ). إذا كنت تشعر أنك بحاجة إلى تحكم أكثر صرامة في الكتابة ، فيمكنك التفكير في استخدام التعليقات التوضيحية للكتابة في كود JS العادي (هنا سيساعدك
التدفق من Facebook). وإذا كنت مستعدًا لكتابة التعليمات البرمجية المكتوبة بالكامل تقريبًا - انتبه إلى
TypeScript .
تجدر الإشارة إلى أنه في عام 2018 اكتسبت TypeScript شعبية كبيرة ، بالإضافة إلى ذلك ، هناك شعور بأن هناك كل المتطلبات الأساسية لتأسيس نفسها بقوة في Node.js. إذا كنت تبحث بجدية عن TypeScript ، فيجب أن تسأل نفسك إذا كنت تفكر فقط في الكتابة ، أو عن ميزات اللغة الأخرى. النقطة المهمة هنا هي أن العمل مع شيء ما مثل الواجهات والفصول المجردة سيعني أنك ستجد نفسك في بيئة حيث ، بالكاد تفكر في الكتابة ، بالكاد ستدخلها.
2. إيلاء الاهتمام لقدرات linter
تؤخذ هذه الأيام من المسلمات Linters. بعد الإعداد البسيط ، لديك تحت تصرفك أداة لمساعدتك في العثور على أخطاء في الكود. لقد ولت الأيام التي كان فيها رمز linting يعني في المقام الأول السيطرة على تصميمه (شيء مثل وجود أو عدم وجود فواصل منقوطة). يمكن الآن للناشئين تحديد المشكلات الخطيرة - مثل الأخطاء التي لا يتم التعامل معها بشكل صحيح ، والوعود التي لم يتم حلها أبدًا ، والمشاكل الأخرى المماثلة التي لن يدرجها أحد بوعي في التعليمات البرمجية الخاصة بهم. لذلك ، إذا كنت لا تستخدم linter حتى الآن ، فقد حان الوقت للقيام بذلك ، دون أن تنسى تكوينه المدروس. هنا ، على سبيل المثال ، هو مكون إضافي لـ
ESLint ،
eslint-plugin-chai-expect ، والذي يمكنه اكتشاف الاختبارات المكونة عن طريق الخطأ. هنا هو
البرنامج المساعد eslint-plugin-وعد الذي يكتشف الوعود التي لم يتم حلها (رمز مع مثل هذه الوعود ، دون سبب واضح ، يتوقف ببساطة). باستخدام
المكون الإضافي eslint-plugin-security ، من الممكن العثور على تعبيرات عادية غير آمنة في الكود يمكن استخدامها من قبل المهاجمين لتنفيذ هجمات DOS.
3. تعميق معرفتك بهندسة مشاريع البرامج من خلال تبني شيء من عالم Java ونسيان الكثير من عالم Ruby
يثير النظام الإيكولوجي لـ Node.js بشكل متكرر موضوع هندسة وتصميم نظم المعلومات. لذلك ، يتحدث الجميع عن الخدمات الصغيرة ، لكن القليل فقط منهم يتحدثون عن بنيتها الداخلية. نتيجة لذلك ، فإن معظم تطبيقات Node.js هي أمثلة لتطبيق مفاهيم MVC وغيرها من الأنماط المشكوك فيها من عالم روبي. ما هو سيء للغاية في ذلك؟ على سبيل المثال ، تم إنشاء قالب MVC لتبسيط العمل مع البيانات ، ولكن هذا القالب غير مناسب لتصميم أجزاء خادم موثوقة من التطبيقات. يقول بوب مارتن ، على سبيل المثال ،
إن MVC هي آلية لتوصيل البيانات إلى مستخدم ، وليست بنية تطبيقية. هل من الممكن وصف منطق العمل لتطبيق microservice ، وقواعد تشغيله ، وميزات الوصول إلى البيانات ، والتفاعل مع الخدمات الصغيرة الأخرى باستخدام فئتين فقط -
Controller Model ؟
تجدر الإشارة إلى أنني لا أريد على الإطلاق التوصية باستخدام قوالب Java / Spring في Node.js هنا (بعد كل شيء ، لم يكن من قبيل الصدفة أن تحولنا إلى Node.js لتطوير برامج الخادم؟). أنصحك أن تقترض فقط بعض الأفكار التي ، من ناحية ، يمكن أن يكون لها تأثير مفيد على بنية التطبيق ، ومن ناحية أخرى ، لن تتسبب في تعقيدها بشكل مفرط.
فيما يلي بعض الإرشادات لأولئك الذين يهتمون بمشاريع Node.js:
- قراءة القسم الأول من هذه المقالة على بنية التطبيق Node.js.
- حاول ألا تخلط بين منطق أعمال التطبيق وكائنات Express ، اقرأ حول مبادئ التصميم المحرك بالمجال (DDD) والهندسة السداسية .
- يؤدي استخدام نمط Active Record ، والذي يحظى بشعبية كبيرة بين المطورين الذين يستخدمون Mongoose و Sequelize ، بسهولة إلى ظهور كائنات محمّلة بأعباء يصعب اختبارها. النظر في استخدام نمط معين البيانات بدلا من نمط السجل النشط.
- تحقق من الكود الخاص بمشروع Node.js النموذجي المصنوع جيدًا ، والذي يتميز بهندسة الجودة التي تنفذ مبادئ DDD.
4. فكر في كيفية استخدام async_hooks Node.js-API الجديد عند العمل مع التعليمات البرمجية غير المتزامنة
يحتوي نموذج تنفيذ تعليمات برمجية أحادية السلسلة المستخدم في JavaScript على عيب واحد خطير - العمليات غير المتزامنة ، على سبيل المثال ، الطلبات ، فقد السياق. لا يتم حفظه أثناء دورة حياة الاستعلام ، نظرًا لأن العمليات غير المتزامنة تشارك في تنفيذها. لماذا هذا سيء؟ على سبيل المثال ، يسعى المطورون غالبًا إلى تضمين معرّفات استعلام فريدة في إدخالات دفتر اليومية ، والتي ، عند تحليل هذه السجلات ، تسمح لأحدهم بتحديد تلك المتعلقة بالاستعلام نفسه. اليوم ، في عام 2018 ، هذا ليس بالأمر السهل. في العام القادم ، هناك شيء جديد ينتظرنا ، وهو أننا نتحدث عن الخطافات غير المتزامنة ، واجهة برمجة تطبيقات
async_hooks . هذا لا يعني أن هذه فرصة جديدة تمامًا ، والمقصود هو أنه ينبغي أن يترك النظام التجريبي قريبًا. ببساطة ، تسمح السنانير غير المتزامنة للمطور بتنفيذ تعليمات برمجية أصلية في بعض النقاط في دورة حياة العملية غير المتزامنة. مع وضع ذلك في الاعتبار ، يمكنك تنسيق الإجراءات التي يتم تنفيذها بواسطة تعليمات برمجية غير متزامنة والحفاظ على السياق. تضع هذه الميزة الأساس لتطوير الحزم التي ستنقل Node.js إلى مستوى جديد في تتبع العمليات غير المتزامنة والعمل مع السياق.
على سبيل المثال ، تتيح لك الحزمة
cls-hooked تنظيم استخدام المتغيرات والسياق طوال دورة حياة العملية غير المتزامنة. تسمح لك حزمة
jaeger-client بتصور عملية تمرير الطلب عبر الأنظمة ، حتى من خلال الخدمات الصغيرة والخوادم (يتم تطبيق معيار Javascript OpenTracing API 1.0 هنا).
في ما يلي المواد لمعرفة المزيد حول استخدام واجهة برمجة تطبيقات async_hooks.
5. فهم أحدث التقنيات "الخالية من الخوادم" الجاهزة بالفعل للمشاريع الجادة والقادرة على قتل Kubernetes
نحن هنا نستخدم مفاهيم FaaS (وظيفة كخدمة ، تعمل كخدمة) و "تقنيات بدون خادم" كمرادفات ، على الرغم من أنها لا تعني نفس الشيء. على وجه الخصوص ، أدناه سنتحدث عن خدمات FaaS السحابية.
في البداية ، كانت تقنية FaaS تهدف إلى تطوير مهام متناهية الصغر ، وليس لإنشاء تطبيقات "ميكروسيرفيس" كاملة. أدى تزايد شعبية منصات FaaS إلى زيادة اهتمام مقدمي الخدمات السحابية ، وقد اكتسبت منصات FaaS ميزات جديدة. نتيجة لذلك ، على الرغم من أن هذا غير متوقع ، إلا أن هناك شعورًا بأن منصات FaaS في 2019 يمكن أن تصبح أساسًا للمشاريع الجادة. هل يمكن لهذه المنصات التنافس مع Kubernetes واستخدامها لاستضافة التطبيقات الكبيرة؟ يرى البعض في تقنيات الحوسبة بدون خوادم وتقنية FaaS شيئًا جديدًا تمامًا ، ولكن في الممارسة العملية ، سيتعين على كل منشئ تطبيق السحابة الاختيار بين التقنيات الثلاث في 2019. يتم تقديم هذا الاختيار ، حرفيًا ، على مواقع مزودي الخدمات السحابية. وهي نتحدث عن اختيار واحد من ثلاثة خيارات:
- خادم السحاب العادي (مثل VDS من RUVDS)
- Kubernetes
- FaaS
نتيجة لذلك ، من المهم للغاية في عصرنا أن نتمكن من مقارنة قدرات Kubernetes مع FaaS وتوقع عواقب اختيار تقنية معينة.
6. تحقق من ابتكارات JavaScript التي ستصبح قياسية قريبًا.
لا يمكنني أن أسمي نفسي داعمًا للبحث عن أحدث ميزات اللغة واستخدامها ، لأن استخدامها يضعف أحيانًا بساطة الشفرة وفهمها. ولكن من وقت لآخر ، تظهر ميزات جافا سكريبت القيمة حقًا (مثل إنشاء المزامنة / الانتظار منذ عامين) ، لذلك من المفيد النظر إلى قائمة
عروض TC39 ومورد node.green للتعرف مسبقًا على الميزات الجديدة التي قد تناسبك. إليكم ما يثير الاهتمام هنا:
- حقول الفصل هي الآن في المرحلة 3 (الأخيرة) من الموافقة ، ويمكنهم إدخال المعيار في عام 2019.
- يمر نوع بيانات BigInt أيضًا بمرحلة المصالحة النهائية. يمكن أن يساعد استخدام الأرقام من هذا النوع في تنظيم التفاعل مع خدمات microservices أو أي أنظمة ، يتم خلالها استخدام أرقام ضخمة.
- التكرارات غير المتزامنة وطريقة الوعد () الأخيرة تم قبولها بالفعل. إذا لم تكن قد اهتمت بها بعد - فاقرأها.
7. إتقان تقنية واحدة على الأقل لإنشاء واجهة برمجة تطبيقات. إيلاء الاهتمام ل GraphQL
يعد REST-API أداة رائعة لحل فئة معينة من المهام. وهي نتحدث عن إدارة الاستعلامات وتعديل السجلات في قواعد البيانات. هل يركز نظامك على العمل مع البيانات المالية؟ ربما ، لضمان تشغيلها ، من الضروري مراعاة أشد القيود واستخدام نموذج بيانات تم تطويره بعناية لا يسمح بالغموض. تعتبر تقنية REST مناسبة لك في هذه الحالة ، لكنها لا تظهر بشكل جيد للغاية في المواقف الأخرى الشائعة جدًا ، على سبيل المثال ، عندما يؤدي تنفيذ الطلب نفسه إلى استلام مجموعات بيانات مختلفة. الأمر نفسه ينطبق على العمل في ظروف سرعات الاتصال المنخفضة ، عندما يكون من الضروري إرسال أقل قدر ممكن من البيانات عند العمل مع واجهة برمجة تطبيقات معينة. مثل هذه المواقف تشمل الاتصالات بين أجهزة الكمبيوتر ، حيث تأتي الاتصالات عالية السرعة في المقدمة. هل يستحق الأمر في مثل هذه الحالات التحول إلى شيء جديد؟ لا ، لا يستحق كل هذا العناء. من الأفضل إضافة شيء جديد إلى ما هو مستخدم بالفعل. واجهة برمجة التطبيقات ليست بنية تطبيقية. هذه مجرد نقطة وصول إلى التطبيق ، مما يعني أن واجهات برمجة التطبيقات التي تم إنشاؤها باستخدام أدوات مختلفة يمكن أن تتعايش. حتى لو كانت جميعها مبنية على أعلى إطار ويب واحد مثل Express.
ما التكنولوجيا للدراسة؟ ربما ، في الظروف الحالية ، يجدر المراهنة على تقنية GraphQL ، التي أصبحت أكثر وأكثر شعبية. لقد نضج النظام الإيكولوجي لهذه التكنولوجيا بشكل كبير ، فهو يخدم بعض سيناريوهات البيانات الشائعة للغاية - مثل البحث الديناميكي والتفاعل مع مصادر البيانات الهرمية. من ناحية أخرى ، لا تزال تقنية gRPC حلاً عالي التخصص ومناسب تمامًا للتواصل بين الخوادم في المواقف عندما يكون من المستحسن أثناء تبادل البيانات نقل أقل قدر ممكن من معلومات الخدمة (على سبيل المثال ، نحن نتحدث عن أنظمة تبادل البيانات القائمة على " الناشر-المشترك "، أو حول تلك التي تستخدم فيها الرسائل وقوائم انتظار الرسائل). فيما يلي بعض المنشورات المفيدة حول هذا الموضوع:
8. باستخدام اختبارات الوحدة والتكامل؟ ألقِ نظرة على تقنيات الاختبار الجديدة.
هل أنت معتاد بالفعل على هرم الاختبار ، مع اختبارات الوحدة والتكامل والاختبارات الشاملة؟ إذا كان الأمر كذلك - عظيم. كل هذا يعتمد على استراتيجيات الاختبار الناجحة. ومع ذلك ، تجدر الإشارة إلى أنه على مدار السنوات العشر الماضية ، تغير عالم تطوير البرامج بشكل خطير للغاية ، وبقيت نماذج الاختبار على حالها ، الأمر الذي يثير لنا أسئلة حول كيفية اختبار خدمات micros ، وتطبيقات الإنترنت الغنية ، والأنظمة الخالية من الخوادم. تكمل بعض الأساليب الحديثة للاختبار المجموعة التقليدية من التقنيات ، وقد يحل بعضها محلها ، وبالتالي تحسين استراتيجية الاختبار والنتائج. إليك ما يمكنك قراءته ونرى:
- تساعد أنظمة الاختبار المبنية على نمط عقود يحركها المستهلك في منع فشل واجهات برمجة التطبيقات الخاصة بالخوادم التي تستخدمها الخدمات المصغرة أو العملاء.
- يمكن استخدام الاختبار باستخدام اللقطات ، ليس فقط في الواجهة الأمامية ، ولكن أيضًا في مشاريع الخوادم.
- اختبار المكونات هو نهج متوازن لاختبار الخدمات الصغيرة.
- إليك مقطع فيديو حول الأساليب الحديثة لاختبار مشاريع Node.js.
9. اجعل نظام مراقبة التطبيق الخاص بك يتماشى مع أفضل ممارسات SRE / DevOps
في عام 2019 ، يمكن أن يتكون التطبيق متوسط الحجم من عشرات المكونات. لضمان التشغيل السلس لهذه البنية التحتية ، يجب مراقبتها بعناية. على الرغم من وضوح ما سبق ، لا يزال معظم المطورين لا يعتبرون من المهم دراسة واستخدام هذه التوصيات لمراقبة التطبيقات وإنشاء نظام تنبيهات حول المشكلات التي يمكن أن يقدمها لهم المتخصصون المسؤولون عن موثوقية مشاريع الويب. على سبيل المثال ، يركز المطورون غالبًا على المؤشرات الداخلية لأداء النظام ، مثل سرعة المعالج أو ذاكرة الوصول العشوائي ، بدلاً من القلق بشأن المقاييس التي تؤثر بشكل مباشر على المستخدمين النهائيين. على وجه الخصوص ، نحن نتحدث عن وتيرة الأخطاء والتأخير. وهذا ما
يسمى "الرصد القائم على الأعراض". تسمى هذه المؤشرات الموجهة نحو المستخدم أحيانًا "إشارات ذهبية" ، وأنت ، ربما تقوم بإدخال نظام مراقبة ، تقرر البدء بإدخال مثل هذه المقاييس. هنا المواد ذات الصلة:
- 4 "إشارات ذهبية" للرصد .
- فصل حول مراقبة النظام الموزعة من هندسة موثوقية الموقع من Google.
- يمكن أن تكون حزمة احصائيات الطلب مفيدة في جمع المقاييس المناسبة ، والتي يمكن بعد ذلك نقلها إلى نظام المراقبة.
10. تحسين أمن المشاريع من خلال النظر إليها من وجهة نظر المهاجم ، وكذلك تعلم كيفية إجراء الهجمات وأدوات القرصنة
إذا كنت لا تستطيع التفكير مثل شخص يريد مهاجمة نظامك ، فهذا يعني أنه لا يمكنك التفكير مثل المدافع عن هذا النظام سوف يفكر. في عام 2019 ، يجب ألا تقوم بنقل المهام لحماية المشاريع إلى جهات خارجية ، ولا تعتمد فقط على أجهزة تحليل الأمان الثابتة. يوجد اليوم عدد كبير من أنواع الهجمات (أحدث الاتجاهات في هذا المجال هي
الهجمات على البنية التحتية للتطوير وعلى npm). في الوقت نفسه ، تتغير التطبيقات بسرعة كبيرة جدًا - أمس تم الاعتراف بالمشروع على أنه يتمتع بحماية جيدة ، وغداً يمكنهم إضافة العديد من خدمات AWS الجديدة ، والعديد من أنواع قواعد البيانات الجديدة ودور IAM الجديد. في الوقت نفسه ، لن يكون قريبًا تحليل سلامة المشروع. والنتيجة هي أن المطورين يشكلون أكبر المخاطر الأمنية على مشاريعهم. الحل لهذه المشكلة هو تدريبهم. هذا يعني أن كل مطور لمشاريع الويب يحتاج إلى جعل تطبيق قواعد الأمان شبه تلقائي ، وكل ما يفعله ، يتذكر دائمًا السلامة.
بعد أن تقرر التحرك في هذا الاتجاه ، اتضح أن مراعاة الأمان عند القيام بأي عمل ليس مخيفًا للغاية. قل ، بعد أن تعرفت على الأساليب والأدوات الشائعة للهجوم ، ارسم مخططًا لبنية تطبيقك وفكر في كيفية مهاجمتك. بمرور الوقت ، حتى دون أن تقدم لنفسك تقريراً في هذا ، سوف تبدأ في مراعاة مشكلات الأمان ، واتخاذ كل قرار معماري وإدخال كل سطر جديد من التعليمات البرمجية في المحرر. فيما يلي بعض الأفكار لإدارة مشكلات الأمان:
- جرب OWASP ZAP - أداة متعددة الوظائف للبحث في الأنظمة والقرصنة ، والتي تتيح حتى للمبتدئين معرفة مستوى أمان التطبيق.
- تحقق من هذه القائمة من توصيات الأمان Node.js لأكثر من عشرين أفكار الهجوم وأمثلة رمز جافا سكريبت.
- قم بجدولة اجتماع شهري لتحليل التهديدات حيث سيقوم فريق المشروع بدراسة هندسته وتقديم هجمات عليه. إذا بدت هذه الفكرة مملة لك - فيمكنك تدليل مثل هذه الاجتماعات. قل ، أولئك الذين يجدون الضعف يمكن مكافأتهم بطريقة أو بأخرى. يمكنك أيضًا ، على سبيل المثال ، تقسيم المشاركين في هذا الاجتماع إلى فريقين وترتيب منافسة بينهما للعثور على نقاط الضعف.
11. تصميم وتنفيذ استراتيجية تحديث حزمة npm. أظهر عام 2018 أن التسرع عند تحديثها أمر خطير
عادة ، تلتزم فرق التطوير بإحدى "استراتيجيتين" لتحديث حزم npm. إما أن يقوموا بتحديثها بأسرع ما يمكن بعد إصدار إصداراتهم الجديدة ، وأحيانًا حتى أتمتة هذه العملية ، أو ليس لديهم استراتيجية لتحديث الحزمة على الإطلاق. مع هذا النهج ، يتم تحديث الحزم بشكل غير منتظم ، وبدءًا من هذه العملية ، يتم توجيهها بشيء يشبه الفكر المفاجئ: "هل يجب تحديثنا اليوم؟" على الرغم من أن أول هذه الأساليب يبدو أفضل من الثاني ، إلا أنه تبين بشكل غير متوقع أنه يرتبط بمخاطر أعلى في عام 2018 مقارنة بالثاني. تم اكتشاف المشكلات ، مثل تلك التي حدثت مع حزمة
البث المباشر ، بواسطة المجتمع في غضون بضعة أيام ، وأولئك الذين لم يتعجلوا التحديث أمر آمن.
ضع في اعتبارك إضفاء الطابع الرسمي على استراتيجية تحديث الحزم التي يعتمد عليها مشروعك ؛ حاول استخدام أدوات التشغيل الآلي لهذه العملية. ابحث عن الحل الوسط بين رفض التحديثات وتحديث الحزم كثيرًا. هنا يمكن لبرنامج
npq مساعدتك ، والذي يتحقق من الحزم أثناء التثبيت ويقدم توصيات. يمكنك إلقاء نظرة على المشاريع التجارية مثل
greenkeeper . عيب هذه الحلول هو أنها لا تستطيع تأجيل التثبيت حتى اللحظة التي سيكون من الواضح فيها أن حزمة معينة آمنة.
12. نلقي نظرة فاحصة على النشر التدريجي للمشاريع
ربما في عام 2019 ، ستعتبر أنه من المعقول نشر مشاريع في الإنتاج باستخدام مخطط تدريجي ، وليس عن طريق إرسال كل ما كان في عملية التطوير إلى خادم قتالي على الفور. وتسمى هذه العملية "نشر الكناري" ، فهي توفر مستوى أعلى من حماية المشروع من النشر المتزامن للرمز الجديد. وعادة ما يميز المراحل الثلاث التالية:
- النشر يتم نشر الكود الجديد في بيئة إنتاج معزولة جديدة (على خدمة Kubernetes الجديدة ، على خادم افتراضي جديد). في هذه المرحلة ، لا يخدم الكود أي شخص حتى الآن ، وبالتالي ، لا يمكن أن يسبب الفشل فيه ضررًا.
- اختبار. الآن ، يمكن للعديد من المتخصصين العمل مع الكود الجديد في ظروف أقرب ما يكون من الأكواد الحقيقية ، حيث يتم نشر الكود في الإنتاج.
- الإصدار بعد أن أظهر الاختبار قابلية تشغيل الشفرة الجديدة ، يتم إتاحته تدريجياً للوصول إلى عدد متزايد من المستخدمين ، وبعد أن تبين أنه يعمل بشكل صحيح بما فيه الكفاية ، يتم التخلص من نسخته القديمة تدريجياً.
إحدى النقاط المهمة التي يجب الإشارة إليها هنا هي أن القيام بعمليات نشر واسعة النطاق في الكناري في عام 2019 سيظل متعة كبيرة للغاية. والحقيقة هي أن هذا يتطلب تنسيق عمل عناصر البنية التحتية للمشروع - مثل التوجيه والمراقبة. وبالتالي ، إذا كنت ترغب في تطبيق تقنية مماثلة ، فيجب أن تبدأ بنشر الكناري البسيط واليدوي جزئيًا. على وجه الخصوص ، يتمثل هذا في حقيقة أنه بعد الانتهاء بنجاح من الاختبارات الأولى ، مع مراعاة مؤشرات المراقبة ، يتم تنفيذ الإضافة اليدوية للخوادم التي تحتوي على إصدار جديد من البرنامج للنظام. اقرأ المزيد عن إصدارات الكناري
هنا . إذا كنت ترغب في أتمتة عملية تنفيذ مثل هذه الإصدارات ، فاحرص على الانتباه إلى منصة
Spinnaker .
13. تحقق من تكنولوجيا Kubernetes التي غزت العالم.
Kubernetes (K8S) , . - . . Kubernetes , , 54% K8S-. —
. K8S — , :
, , Kubernetes, .
14. -,
- — . , .
15. , , ,
, — . , . . , (,
tensorflow.js brain.js , , ).
16.
, . , , . , — .
17. Linux, —
Linux- , , . — , ( — ), Docker, . , , , , , .
, Linux.
18. , Node.js
( Node.js): « . , ». , , ( ). , Node.js, , V8 libuv. , 2019 — , Node.js, , , libuv. , , , Node.js - , .
, .
, npm- C/C++.
Node.js.
Node.js RUVDS.
19. ,
, , . , , , , , . , , , , . JavaScript-, . , JavaScript, . , , TypeScript . flow , , . , - flow, , , , « , ». ? , , «
». , - . , , , — . . , - , , , . , . , 2019 , — .
.
, . — , , , , , , . , , , , , .
ملخص
19 , Node.js-, - , 2019 . , - , .
أعزائي القراء! Node.js- 2019 ?
