2019 में खुद के ऊपर बढ़ने की तलाश में Node.js डेवलपर्स के लिए 19 विचार

सामग्री के लेखक, जिसका अनुवाद हम प्रकाशित करते हैं, ने 19 विचारों को एकत्र किया जो उन नोड्सज डेवलपर्स के लिए उपयोगी हो सकते हैं जो 2019 में अपने पेशेवर स्तर को सुधारना चाहते हैं। जावास्क्रिप्ट की दुनिया बहुत बड़ी है, इसलिए यहां पर चर्चा की जाने वाली हर चीज में महारत हासिल करना केवल अवास्तविक है। यह संभावना नहीं है कि कोई है जो यह सब पूरी तरह से मालिक है। हालाँकि, इस समीक्षा में कुछ आपके लिए उपयोगी हो सकता है।

1. टाइपिंग के बारे में सोचें। टाइपस्क्रिप्ट पर ध्यान दें

यह साबित होता है कि जावास्क्रिप्ट में प्रोग्रामिंग, इसमें उपयोग किए जाने वाले टाइपिंग दृष्टिकोण का उपयोग करके श्रम उत्पादकता में कमी और त्रुटियों की उपस्थिति की ओर जाता है। इसका मतलब यह नहीं है कि आपको यह सुनिश्चित करने का प्रयास करना चाहिए कि सभी कोड दृढ़ता से टाइप किए गए हैं। इसके बजाय, हम इस तथ्य के बारे में बात कर रहे हैं कि जावास्क्रिप्ट में विकसित होने पर, प्रकारों के साथ काम करने के लिए एक निश्चित दृष्टिकोण का चयन करना और उसके साथ रहना अच्छा होगा। इस तरह के दृष्टिकोण कोड पर लगाए गए डेटा के प्रकारों से जुड़े प्रतिबंधों के स्तर से, अन्य चीजों के बीच भिन्न होते हैं। उदाहरण के लिए, यह कुछ बहुत सरल हो सकता है, जैसे कि jsonschema (या joi ) पैकेज का उपयोग करके चेक का आयोजन करना। यदि आपको लगता है कि आपको अधिक कठोर प्रकार के नियंत्रण की आवश्यकता है, तो आप नियमित जेएस कोड में टाइप एनोटेशन का उपयोग करने पर विचार कर सकते हैं (यहां फेसबुक से प्रवाह मदद करेगा)। और अगर आप लगभग पूरी तरह से टाइप किए गए कोड लिखने के लिए तैयार हैं - टाइपस्क्रिप्ट पर ध्यान दें ।

यह ध्यान दिया जाना चाहिए कि 2018 में टाइपस्क्रिप्ट ने गंभीर लोकप्रियता हासिल की, इसके अलावा, एक भावना है कि इसके लिए सभी आवश्यक शर्तें हैं जो खुद को Node.js. में मजबूती से स्थापित करती हैं। यदि आप गंभीरता से टाइपस्क्रिप्ट देख रहे हैं, तो आपको अपने आप से पूछना चाहिए कि क्या आप केवल टाइपिंग के बारे में सोच रहे हैं, या भाषा की अन्य विशेषताओं के बारे में। यहाँ मुद्दा यह है कि इंटरफेस और अमूर्त कक्षाओं जैसी किसी चीज़ के साथ काम करने का मतलब होगा कि आप खुद को एक ऐसे माहौल में पाएंगे, जिसमें मुख्य रूप से टाइपिंग के बारे में सोचते हुए, आप शायद ही इसमें जा पाएंगे।

2. लिंटर की क्षमताओं पर ध्यान दें

इन दिनों के लिए सर्दियां दी जाती हैं। एक साधारण सेटअप के बाद, आपके पास अपने निपटान में एक उपकरण है जो आपको कोड में त्रुटियों को खोजने में मदद करने के लिए है। वे दिन आ गए जब लिंटिंग कोड का मुख्य रूप से अपने डिजाइन को नियंत्रित करना (अर्धविराम की उपस्थिति या अनुपस्थिति जैसी कोई चीज) थी। अब लिंटर्स गंभीर समस्याओं की पहचान कर सकते हैं - जैसे कि त्रुटियों को ठीक से संभाला नहीं जाता है, वादे जो कभी हल नहीं होते हैं, और इसी तरह की अन्य परेशानियां जो कोई भी जानबूझकर अपने कोड में शामिल नहीं करेगा। इसलिए, यदि आप अभी तक लिंटर का उपयोग नहीं कर रहे हैं, तो अब ऐसा करने का समय है, इसके विचारशील कॉन्फ़िगरेशन के बारे में भूलकर भी। यहाँ, उदाहरण के लिए, ESLint , eslint-plugin-chai-उम्मीद के लिए एक प्लगइन है , जो गलत तरीके से रचे गए परीक्षणों का पता लगा सकता है। यहां एस्लिंट-प्लगइन-वादा प्लगइन है जो अनसुलझे वादों का पता लगाता है (ऐसे वादों के साथ कोड, बिना किसी स्पष्ट कारण के, बस रुक जाता है)। एस्लिंट-प्लगइन-सुरक्षा प्लगइन का उपयोग करना, कोड में असुरक्षित नियमित अभिव्यक्ति ढूंढना संभव है जो एक हमलावर द्वारा डॉस हमलों का संचालन करने के लिए उपयोग किया जा सकता है।

3. जावा दुनिया से सीखकर और रूबी दुनिया से बहुत कुछ भूलकर सॉफ्टवेयर प्रोजेक्ट आर्किटेक्चर के अपने ज्ञान को गहरा करें

Node.js का पारिस्थितिकी तंत्र आमतौर पर वास्तुकला और सूचना प्रणालियों के डिजाइन के विषय को उठाता है। यूं तो हर कोई माइक्रोसर्विसेज के बारे में बात कर रहा है, लेकिन बहुत कम लोग ही उसके आंतरिक ढांचे के बारे में बात करते हैं। परिणामस्वरूप, अधिकांश Node.js अनुप्रयोग MVC अवधारणाओं और रूबी दुनिया से अन्य संदिग्ध पैटर्न को लागू करने के उदाहरण हैं। उसके बारे में इतना बुरा क्या है? उदाहरण के लिए, MVC टेम्पलेट डेटा के साथ काम को कारगर बनाने के लिए बनाया गया था, लेकिन यह टेम्पलेट अनुप्रयोगों के विश्वसनीय सर्वर भागों को डिजाइन करने के लिए उपयुक्त नहीं है। उदाहरण के लिए, बॉब मार्टिन का कहना है कि एमवीसी उपयोगकर्ता को डेटा देने के लिए एक तंत्र है, न कि एप्लिकेशन आर्किटेक्चर। क्या केवल दो वर्गों - Controller और Model का उपयोग करके एक माइक्रोसैसवर्क एप्लिकेशन के व्यावसायिक तर्क का वर्णन करना, इसके संचालन के नियम, डेटा एक्सेस की विशेषताएं, अन्य माइक्रोसर्विस के साथ बातचीत करना संभव है?
यह ध्यान दिया जाना चाहिए कि मैं बिल्कुल Node.js में जावा / स्प्रिंग टेम्प्लेट का उपयोग करने की सिफारिश नहीं करना चाहता हूं। (आखिरकार, यह कोई संयोग नहीं था कि हमने सर्वर प्रोग्राम विकसित करने के लिए Node.js पर स्विच किया है?)। मैं आपको केवल कुछ विचारों को उधार लेने की सलाह दूंगा, जो एक तरफ, आवेदन वास्तुकला पर लाभकारी प्रभाव डाल सकता है, और दूसरी ओर, उनकी अत्यधिक जटिलता का कारण नहीं होगा।

यहां उन लोगों के लिए कुछ दिशानिर्देश दिए गए हैं जो Node.js परियोजनाओं की वास्तुकला की परवाह करते हैं:

• इस लेख के पहले भाग को Node.js एप्लिकेशन आर्किटेक्चर पर पढ़ें।
• एक्सप्रेस ऑब्जेक्ट्स के साथ एप्लिकेशन बिजनेस लॉजिक को मिक्स न करने की कोशिश करें, डोमेन-ड्रिवेन डिज़ाइन (डीडीडी) सिद्धांतों और हेक्सागोनल आर्किटेक्चर के बारे में पढ़ें।
• सक्रिय रिकॉर्ड पैटर्न का उपयोग, जो कि मानगो और सीक्लाइज़ का उपयोग करने वाले डेवलपर्स के बीच बहुत लोकप्रिय है, आसानी से अतिभारित वस्तुओं की उपस्थिति की ओर जाता है जो परीक्षण करना मुश्किल है। सक्रिय रिकॉर्ड पैटर्न के बजाय डेटा मैपर पैटर्न का उपयोग करने पर विचार करें।
• इस अच्छी तरह से बनाए गए टेम्पलेट Node.js परियोजना के लिए कोड देखें, जिसमें एक गुणवत्ता वास्तुकला है जो DDD के सिद्धांतों को लागू करता है।

4. अतुल्यकालिक कोड के साथ काम करते समय नए Node.js-API async_hooks का उपयोग करने के बारे में सोचें

जावास्क्रिप्ट में उपयोग किए गए एकल-थ्रेडेड कोड निष्पादन मॉडल में एक गंभीर खामी है - अतुल्यकालिक संचालन, उदाहरण के लिए, अनुरोध, संदर्भ खोना। यह क्वेरी जीवन चक्र के दौरान सहेजा नहीं गया है, क्योंकि अतुल्यकालिक संचालन उनके निष्पादन में शामिल हैं। यह बुरा क्यों है? उदाहरण के लिए, डेवलपर्स अक्सर जर्नल प्रविष्टियों में अद्वितीय क्वेरी पहचानकर्ताओं को शामिल करना चाहते हैं, जो इस तरह के रिकॉर्ड का विश्लेषण करते समय, किसी को उसी क्वेरी से संबंधित पहचान करने की अनुमति देता है। आज, 2018 में, यह इतना आसान नहीं है। अगले साल, कुछ नया हमें इंतजार कर रहा है, अर्थात्, हम अतुल्यकालिक हुक के बारे में बात कर रहे हैं, async_hooks API। यह कहना नहीं है कि यह पूरी तरह से नया अवसर है, मुद्दा यह है कि इसे जल्द ही प्रायोगिक शासन छोड़ देना चाहिए। सीधे शब्दों में कहें तो, अतुल्यकालिक हुक एक डेवलपर को एक अतुल्यकालिक ऑपरेशन के जीवन चक्र में कुछ बिंदुओं पर मूल कोड को निष्पादित करने की अनुमति देते हैं। इसे ध्यान में रखते हुए, आप अतुल्यकालिक कोड द्वारा किए गए कार्यों को समन्वयित कर सकते हैं और संदर्भ बनाए रख सकते हैं। यह सुविधा उन विकासशील पैकेजों की नींव रखती है जो अतुल्यकालिक संचालन पर नज़र रखने और संदर्भ के साथ काम करने के लिए Node.js को एक नए स्तर पर ले जाएंगे।

उदाहरण के लिए, cls-hooked पैकेज आपको एक अतुल्यकालिक ऑपरेशन के जीवन चक्र में चर और संदर्भ के उपयोग को व्यवस्थित करने की अनुमति देता है। Jaeger- क्लाइंट पैकेज आपको सिस्टम के माध्यम से एक अनुरोध पारित करने की प्रक्रिया की कल्पना करने की अनुमति देता है, यहां तक ​​कि माइक्रोसर्विस और सर्वर के माध्यम से भी (जावास्क्रिप्ट ओपनटैरिंग एपीआई 1.0 मानक यहां लागू किया गया है)।

यहाँ async_hooks API का उपयोग करने के बारे में अधिक जानने के लिए सामग्री दी गई है।

5. नवीनतम "सर्वर रहित" प्रौद्योगिकियों को समझें जो पहले से ही गंभीर परियोजनाओं के लिए काफी तैयार हैं और कुबेरनेट्स को मारने में सक्षम हैं

यहाँ हम FaaS की अवधारणा (सेवा के रूप में कार्य, सेवा के रूप में कार्य) और "सर्वर रहित प्रौद्योगिकियों" को समानार्थक शब्द के रूप में उपयोग करते हैं, हालांकि उनका मतलब एक ही बात से नहीं है। विशेष रूप से, नीचे हम क्लाउड फास-सेवाओं के बारे में बात करेंगे।

प्रारंभ में, FaaS तकनीक का उद्देश्य सूक्ष्म कार्यों को विकसित करना था, न कि पूर्णरूपेण "माइक्रोसेवर" अनुप्रयोगों का निर्माण करना। एफएएएस प्लेटफार्मों की बढ़ती लोकप्रियता के कारण क्लाउड सेवा प्रदाताओं की रुचि में वृद्धि हुई है, एफएएएस प्लेटफार्मों ने नई सुविधाएँ प्राप्त की हैं। नतीजतन, हालांकि यह अप्रत्याशित है, एक भावना है कि 2019 में एफएएएस प्लेटफॉर्म गंभीर परियोजनाओं का आधार बन सकता है। क्या ये प्लेटफ़ॉर्म कुबेरनेट्स के साथ प्रतिस्पर्धा कर सकते हैं और बड़े अनुप्रयोगों की मेजबानी के लिए इस्तेमाल किया जा सकता है? कुछ सर्वर रहित कंप्यूटिंग और एफएएएस प्रौद्योगिकियों में देखते हैं जो कुछ पूरी तरह से नए हैं, लेकिन व्यवहार में, क्लाउड एप्लिकेशन के प्रत्येक निर्माता को 2019 में तीन प्रौद्योगिकियों के बीच चयन करना होगा। यह विकल्प, सचमुच, क्लाउड सेवा प्रदाताओं की वेबसाइटों पर प्रस्तुत किया गया है। अर्थात्, हम तीन विकल्पों में से एक को चुनने की बात कर रहे हैं:

1. सामान्य क्लाउड सर्वर (जैसे RUVDS से VDS )
2. Kubernetes
3. Faas

नतीजतन, हमारे समय में फैब के साथ कुबेरनेट की क्षमताओं की तुलना करने में सक्षम होना और एक विशेष तकनीक चुनने के परिणामों का अनुमान लगाना बहुत महत्वपूर्ण है।

6. जल्द ही मानक आने वाले जावास्क्रिप्ट नवाचारों की जाँच करें।

मैं खुद को भाषा की नवीनतम विशेषताओं की खोज और उपयोग का समर्थक नहीं कह सकता, क्योंकि कभी-कभी उनका उपयोग कोड की सादगी और समझदारी को बाधित करता है। लेकिन समय-समय पर, वास्तव में मूल्यवान जावास्क्रिप्ट विशेषताएं दिखाई देती हैं (जैसे दो साल पहले async / प्रतीक्षा निर्माण), इसलिए नई सुविधाओं के बारे में अग्रिम रूप से जानने के लिए TC39 ऑफ़र सूची और नोड.ग्रीन संसाधन को देखना आपके लिए उपयोगी हो सकता है। यहाँ मुझे क्या दिलचस्प मिला:

• वर्ग फ़ील्ड अब अनुमोदन के 3 (अंतिम) चरण पर हैं, वे 2019 में मानक में प्रवेश कर सकते हैं।
• बिगइंट डेटा प्रकार भी सामंजस्य के अंतिम चरण से गुजरता है। इस प्रकार की संख्याओं के उपयोग से माइक्रोसिस्टीवर्स या किसी भी सिस्टम के साथ इंटरैक्शन को व्यवस्थित करने में मदद मिल सकती है, जिसके दौरान बड़ी संख्या का उपयोग किया जाता है।
• अतुल्यकालिक पुनरावृत्तियों और अंत में () वादा विधि पहले ही स्वीकार कर ली गई है। यदि आपने अभी तक उन पर ध्यान नहीं दिया है - तो उन्हें पढ़ें।

7. एक एपीआई बनाने के लिए कम से कम एक तकनीक में मास्टर। ग्राफकॉल पर ध्यान दें

REST-API कार्यों की एक निश्चित श्रेणी को हल करने के लिए एक महान उपकरण है। अर्थात्, हम प्रश्नों के प्रबंधन और डेटाबेस में रिकॉर्ड को संशोधित करने के बारे में बात कर रहे हैं। क्या आपका सिस्टम वित्तीय डेटा के साथ काम करने पर केंद्रित है? संभवतः, इसके संचालन को सुनिश्चित करने के लिए, सख्त प्रतिबंधों का पालन करना और सावधानीपूर्वक विकसित डेटा मॉडल का उपयोग करना आवश्यक है जो अस्पष्टता की अनुमति नहीं देता है। REST तकनीक इस मामले में आपके लिए उपयुक्त है, लेकिन यह अन्य बहुत ही सामान्य स्थितियों में खुद को बहुत अच्छी तरह से नहीं दिखाती है, उदाहरण के लिए, जब एक ही अनुरोध का निष्पादन विभिन्न डेटा सेटों की प्राप्ति के लिए हो सकता है। वही कम कनेक्शन गति की स्थितियों में काम करने के लिए लागू होता है, जब यह आवश्यक होता है कि एक निश्चित एपीआई के साथ काम करते समय जितना संभव हो उतना कम डेटा प्रसारित होता है। ऐसी स्थितियों में कंप्यूटर के बीच कनेक्शन शामिल हैं, जहां उच्च गति संचार सामने आता है। क्या ऐसे मामलों में कुछ नया करने के लिए स्विच करना इसके लायक है? नहीं, इसके लायक नहीं है। पहले से उपयोग में कुछ नया जोड़ना सबसे अच्छा है। एक एपीआई एक आवेदन वास्तुकला नहीं है। यह आवेदन के लिए सिर्फ एक पहुंच बिंदु है, जिसका अर्थ है कि विभिन्न उपकरणों का उपयोग करके बनाए गए एपीआई सह-अस्तित्व में हो सकते हैं। भले ही वे सभी एक्सप्रेस जैसे एकल वेब ढांचे के शीर्ष पर बने हों।

किस तकनीक से करें पढ़ाई? संभवतः, वर्तमान परिस्थितियों में यह ग्राफक्यूएल तकनीक पर दांव लगाने लायक है, जो अधिक से अधिक लोकप्रिय हो रहा है। इस तकनीक का पारिस्थितिकी तंत्र काफी परिपक्व हो गया है, यह कुछ बहुत ही लोकप्रिय डेटा परिदृश्यों को काम करता है - जैसे कि गतिशील खोज और पदानुक्रम डेटा स्रोतों के साथ सहभागिता। दूसरी ओर, जीआरपीसी प्रौद्योगिकी अभी भी एक अत्यधिक विशिष्ट समाधान है जो उन स्थितियों में सर्वर के बीच संचार के लिए अच्छी तरह से अनुकूल है जब डेटा एक्सचेंज के दौरान यह संभव के रूप में छोटी सेवा की जानकारी को स्थानांतरित करने के लिए वांछनीय है (उदाहरण के लिए, हम "के आधार पर डेटा एक्सचेंज सिस्टम के बारे में बात कर रहे हैं" प्रकाशक-ग्राहक ", या उन लोगों के बारे में जहां संदेश और संदेश कतार का उपयोग किया जाता है)। इस विषय पर कुछ उपयोगी पोस्ट इस प्रकार हैं:

• REST, GraphQL और gRPC की तुलना
• Node.js और Express के आधार पर GraphQL सर्वर विकास
• 11 मिनट का YouTube वीडियो ग्राफकॉइन की मूल बातें समझाता है

8. यूनिट और एकीकरण परीक्षणों का उपयोग करना? ब्रांड नई परीक्षण तकनीकों पर एक नज़र डालें।

क्या आप पहले से ही परीक्षण पिरामिड, यूनिट, एकीकरण और एंड-टू-एंड परीक्षणों से परिचित हैं? यदि ऐसा है - महान। यह सब सफल परीक्षण रणनीतियों को रेखांकित करता है। हालांकि, यह ध्यान दिया जाना चाहिए कि पिछले 10 वर्षों में, सॉफ्टवेयर विकास की दुनिया बहुत गंभीरता से बदल गई है, और परीक्षण मॉडल समान बने हुए हैं, जो हमें माइक्रोसेवा, अमीर इंटरनेट अनुप्रयोगों, सर्वर रहित सिस्टम का परीक्षण करने के तरीके के बारे में सवाल उठाता है। परीक्षण के कुछ आधुनिक दृष्टिकोण, प्रौद्योगिकी के पारंपरिक सेट के पूरक हैं, और कुछ इसे बदल भी सकते हैं, जिससे परीक्षण की रणनीति और परिणाम में सुधार होगा। यहाँ आप के बारे में पढ़ सकते हैं और देख सकते हैं:

• कंज्यूमर-ड्रिव्ड कॉन्ट्रैक्ट्स पैटर्न पर बनी टेस्टिंग सिस्टम माइक्रो सर्वर या क्लाइंट्स द्वारा इस्तेमाल किए जाने वाले सर्वर एपीआई को फेल होने से रोकने में मदद करता है।
• स्नैपशॉट का उपयोग करके परीक्षण न केवल फ्रंटेंड में, बल्कि सर्वर प्रोजेक्ट में भी उपयोग किया जा सकता है।
• घटक परीक्षण सूक्ष्मदर्शी परीक्षण के लिए एक संतुलित दृष्टिकोण है।
• यहाँ Node.js परियोजनाओं के परीक्षण के लिए आधुनिक दृष्टिकोणों के बारे में एक वीडियो है।

9. SRE / DevOps सर्वोत्तम प्रथाओं के अनुरूप अपना एप्लिकेशन मॉनिटरिंग सिस्टम लाएं

2019 में, यहां तक ​​कि एक मध्य-आकार के अनुप्रयोग में दर्जनों घटक शामिल हो सकते हैं। इस तरह के बुनियादी ढांचे के सुचारू संचालन को सुनिश्चित करने के लिए, इस पर सावधानीपूर्वक निगरानी की जानी चाहिए। उपरोक्त की स्पष्टता के बावजूद, अधिकांश डेवलपर्स अभी भी अनुप्रयोगों की निगरानी और उन समस्याओं के बारे में अलर्ट बनाने के लिए उन सिफारिशों का अध्ययन और उपयोग करना महत्वपूर्ण नहीं मानते हैं जो वेब परियोजनाओं की विश्वसनीयता के लिए जिम्मेदार विशेषज्ञों द्वारा उन्हें दी जा सकती हैं। उदाहरण के लिए, डेवलपर्स अक्सर सिस्टम प्रदर्शन के आंतरिक संकेतकों पर ध्यान केंद्रित करते हैं, जैसे प्रोसेसर की गति या रैम, मैट्रिक्स के बारे में चिंता करने के बजाय सीधे उपयोगकर्ताओं को प्रभावित करते हैं। विशेष रूप से, हम त्रुटियों और देरी की आवृत्ति के बारे में बात कर रहे हैं। इसे "लक्षण-आधारित निगरानी" कहा जाता है । ऐसे उपयोगकर्ता-उन्मुख संकेतक को कभी-कभी "गोल्डन सिग्नल" कहा जाता है, और आप, संभवतः एक निगरानी प्रणाली शुरू कर रहे हैं, ऐसे मैट्रिक्स की शुरूआत के साथ शुरू करने का निर्णय लेते हैं। यहाँ संबंधित सामग्री हैं:

• निगरानी के 4 "गोल्डन सिग्नल" ।
• Google की साइट विश्वसनीयता इंजीनियरिंग से वितरित सिस्टम मॉनिटरिंग का एक अध्याय ।
• अनुरोध-आँकड़े पैकेज उपयुक्त मीट्रिक एकत्र करने में उपयोगी हो सकता है, जिसे तब निगरानी प्रणाली में स्थानांतरित किया जा सकता है।

10. एक हमलावर के दृष्टिकोण से उन्हें देखने के साथ-साथ हमले और हैकर उपकरण का संचालन करने के तरीके सीखने के साथ परियोजनाओं की सुरक्षा में सुधार करें

यदि आप किसी ऐसे व्यक्ति के बारे में नहीं सोच सकते हैं जो आपके सिस्टम पर हमला करना चाहता है, तो इसका मतलब है कि आप सोच नहीं सकते कि इस प्रणाली के रक्षक सोचेंगे। 2019 में, आपको तीसरे पक्ष को परियोजनाओं की सुरक्षा के लिए न तो कार्यों को स्थानांतरित करना चाहिए, न ही केवल स्थैतिक सुरक्षा विश्लेषक पर भरोसा करना चाहिए। आज भारी संख्या में हमले हैं (इस क्षेत्र में नवीनतम रुझान विकास के बुनियादी ढांचे और एनपीएम पर हमले हैं)। उसी समय, एप्लिकेशन बहुत जल्दी बदल जाते हैं - कल परियोजना को अच्छी तरह से संरक्षित माना गया था, और कल वे कई नई एडब्ल्यूएस सेवाएं, कई नए प्रकार के डेटाबेस और एक नई आईएएम भूमिका जोड़ सकते हैं। इसी समय, यह परियोजना की सुरक्षा का विश्लेषण करने के लिए जल्द ही नहीं होगा। इसका परिणाम यह है कि डेवलपर्स अपनी परियोजनाओं के लिए सबसे बड़ा सुरक्षा जोखिम रखते हैं। इस समस्या का समाधान उनका प्रशिक्षण है। इसका मतलब यह है कि वेब परियोजनाओं के प्रत्येक डेवलपर को सुरक्षा नियमों के कार्यान्वयन को लगभग स्वचालितता में लाने की आवश्यकता है, और वह जो कुछ भी करता है, हमेशा सुरक्षा को याद रखता है।

जब आप इस दिशा में जाने का निर्णय लेते हैं, तो यह पता चलता है कि किसी भी कार्य को करते समय सुरक्षा को ध्यान में रखना इतना डरावना नहीं है। कहते हैं, अपने आप को हमला करने के सामान्य तरीकों और उपकरणों से परिचित होने के बाद, अपने आवेदन की वास्तुकला का एक चित्र बनाएं और सोचें कि आप इस पर कैसे हमला करेंगे। समय के साथ, यहां तक ​​कि अपने आप को इस बारे में एक रिपोर्ट दिए बिना, आप सुरक्षा मुद्दों को ध्यान में रखना शुरू कर देंगे, प्रत्येक वास्तु निर्णय लेंगे और संपादक में हर नई पंक्ति में प्रवेश करेंगे। सुरक्षा मुद्दों के प्रबंधन के लिए यहां कुछ विचार दिए गए हैं:

• OWASP ZAP की कोशिश करें - सिस्टम और हैकिंग के लिए एक बहुआयामी उपकरण, जो एप्लिकेशन सुरक्षा के स्तर को जानने के लिए एक शुरुआत की भी अनुमति देता है।
• दो दर्जन से अधिक हमले के विचारों और जावास्क्रिप्ट कोड उदाहरणों के लिए Node.js सुरक्षा सिफारिशों की इस सूची को देखें।
• एक मासिक धमकी विश्लेषण बैठक का शेड्यूल करें जहां प्रोजेक्ट टीम अपनी वास्तुकला का अध्ययन करेगी और उस पर हमले की पेशकश करेगी। यदि इस तरह का विचार आपको उबाऊ लगता है - तो आप ऐसी बैठकों को रद्द कर सकते हैं। कहते हैं, जो लोग भेद्यता पाते हैं उन्हें किसी भी तरह से पुरस्कृत किया जा सकता है। उदाहरण के लिए, आप इस तरह की बैठक के प्रतिभागियों को दो टीमों में विभाजित कर सकते हैं और कमजोरियों को खोजने के लिए उनके बीच एक प्रतियोगिता की व्यवस्था कर सकते हैं।

11. npm पैकेज अद्यतन रणनीति को डिज़ाइन और कार्यान्वित करें। 2018 ने दिखाया कि उन्हें अपडेट करते समय जल्दबाजी खतरनाक है

आमतौर पर, विकास टीम npm संकुल को अद्यतन करने के लिए दो "रणनीतियों" में से एक का पालन करती हैं। वे या तो अपने नए संस्करणों की रिलीज़ के बाद जितनी जल्दी हो सके उन्हें अपडेट करते हैं, कभी-कभी इस प्रक्रिया को स्वचालित भी करते हैं, या उनके पास पैकेज अपडेट की रणनीति नहीं होती है। इस दृष्टिकोण के साथ, पैकेजों को अनियमित रूप से अपडेट किया जाता है, और, इस प्रक्रिया को शुरू करते हुए, उन्हें अचानक विचार की तरह कुछ निर्देशित किया जाता है: "क्या हमें आज अपडेट किया जाना चाहिए?" हालाँकि इनमें से पहला दृष्टिकोण दूसरे की तुलना में बेहतर है, लेकिन यह अप्रत्याशित रूप से दूसरे की तुलना में 2018 में उच्च जोखिम के साथ जुड़ा हुआ है। समस्याएँ, जैसे कि फ्लैट-स्ट्रीम पैकेज के साथ हुई, कुछ दर्जन दिनों के भीतर समुदाय द्वारा खोज की गई थीं, और जो लोग अद्यतन करने के लिए जल्दी में नहीं थे, वे सुरक्षित थे।

उन पैकेजों को अपडेट करने की रणनीति को औपचारिक रूप देने पर विचार करें, जिन पर आपकी परियोजना निर्भर करती है; इस प्रक्रिया के लिए स्वचालन साधनों का उपयोग करने पर विचार करें। बहुत बार अद्यतन करने और पैकेजों को अद्यतन करने से इनकार करने के बीच बीच का रास्ता खोजें। यहां npq प्रोग्राम आपकी मदद कर सकता है , जो स्थापना के दौरान पैकेजों की जांच करता है और सिफारिशें देता है। आप ग्रीनकीपर जैसी व्यावसायिक परियोजनाओं पर एक नज़र डाल सकते हैं। ऐसे समाधानों का नुकसान यह है कि वे उस समय तक स्थापना को स्थगित नहीं कर सकते हैं जब यह बिल्कुल स्पष्ट हो जाएगा कि एक निश्चित पैकेज सुरक्षित है।

12. परियोजनाओं की चरणबद्ध तैनाती पर करीब से नज़र डालें

शायद 2019 में आप चरणबद्ध योजना का उपयोग करके उत्पादन में परियोजनाओं को तैनात करना उचित समझेंगे, न कि झटपट सर्वर को विकास प्रक्रिया में आने वाली हर चीज को तुरंत भेजकर। इस प्रक्रिया को "कैनरी तैनाती" कहा जाता है, यह नए कोड की एक साथ तैनाती की तुलना में परियोजना सुरक्षा का एक उच्च स्तर देता है। यह आमतौर पर निम्नलिखित तीन चरणों को अलग करता है:

1. तैनाती। नया कोड एक नए, पृथक उत्पादन वातावरण (नए Kubernetes सेवा पर, एक नए वर्चुअल सर्वर पर) में तैनात किया गया है। इस स्तर पर, कोड अभी तक किसी की सेवा नहीं करता है, इसलिए, इसमें विफलताएं नुकसान का कारण नहीं बन सकती हैं।
2. परीक्षण। अब, कई विशेषज्ञ नए कोड के साथ परिस्थितियों में काम कर सकते हैं जो वास्तविक लोगों के करीब हैं, क्योंकि कोड उत्पादन में तैनात है।
3. छोड़ें। परीक्षण के बाद नए कोड के संचालन को दिखाया गया है, इसे धीरे-धीरे उपयोगकर्ताओं की बढ़ती संख्या तक पहुंच प्रदान की जाती है, और यह पता चलने के बाद कि यह मज़बूती से काम करता है, इसका पुराना संस्करण धीरे-धीरे उपयोग से बाहर हो गया है।

यहां एक महत्वपूर्ण बात यह है कि 2019 में पूर्ण-पैमाने पर कैनरी की तैनाती करना अब भी बहुत महंगा होगा। तथ्य यह है कि इसके लिए परियोजना के बुनियादी ढांचे के काम के समन्वय की आवश्यकता है - जैसे मार्ग और निगरानी। इस प्रकार, यदि आप एक समान तकनीक लागू करना चाहते हैं, तो आपको एक साधारण, आंशिक रूप से मैनुअल, कैनरी तैनाती के साथ शुरू करना चाहिए। विशेष रूप से, यह इस तथ्य में शामिल है कि पहले परीक्षणों के सफल समापन के बाद, निगरानी के संकेतकों को ध्यान में रखते हुए, सिस्टम के लिए सॉफ्टवेयर के एक नए संस्करण के साथ सर्वर के मैनुअल एडिशन का प्रदर्शन किया जाता है। कैनरी रिलीज़ के बारे में यहाँ और पढ़ें। यदि आप ऐसी रिलीज़ करने की प्रक्रिया को स्वचालित करना चाहते हैं, तो स्पिनंकर प्लेटफ़ॉर्म पर ध्यान दें।

13. कुबेरनेट्स तकनीक की जाँच करें जिसने दुनिया को जीत लिया है।

Kubernetes (K8S) , . - . . Kubernetes , , 54% K8S-. — . K8S — , :

• Istio
• K-Native
• Kubernetes
• Kubernetes
• Kubernetes
• Helm
• Scaffold

, , 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 ?