Node.JS पर वेब विकास: भाग 1

मेरी परियोजना के हब पर पीआर को एक सप्ताह बीत चुका है " क्या करना है? "। मैं आपको याद दिलाता हूं कि यह परियोजना एक औसत वेब परियोजना को पूरी तरह से जावास्क्रिप्ट (Node.JS) में विकसित करने के लिए एक प्रयोग के रूप में शुरू हुई थी। अब मैं समुदाय को इस प्रयोग के परिणाम, उपयोगी अनुभव प्राप्त करने के साथ-साथ उस पर अंकित रेक के साथ एक विस्तृत मानचित्र साझा करना चाहता हूं।

एपिसोड 1: द बिगनिंग ऑफ़ द वे

मैंने निम्नलिखित लक्ष्य निर्धारित किए हैं:

• समझें कि एनओडी.जेएस पर नियमित वेब-परियोजनाओं को विकसित करना कितना सुविधाजनक है;
• Node.JS पर उपयोग की गई अन्य तकनीकों के साथ विकास की गति की तुलना करें (मेरे मामले में यह PHP और जावा था);
• उन नुकसानों के लिए जाओ जो आपको कई सिंथेटिक उदाहरणों में नहीं मिलते हैं;
• तैयार परियोजना के काम का मूल्यांकन करें: स्थिरता, तनाव का प्रतिरोध, इस तरह की परियोजना की सहायता और विकास की जटिलता।

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

सभी रूपरेखाओं में से, चुनाव एक्सप्रेस पर गिर गया। यह मुझे कम से कम अधिकता के साथ अतिभारित लग रहा था और साथ ही यह मेरी आवश्यकताओं को पूरी तरह से पूरा करता था और इसे आसानी से तीसरे पक्ष के मॉड्यूल के साथ पूरक किया जा सकता था।

फ्रेमवर्क से, मैं निम्नलिखित चाहता था:

• एमवीसी वास्तुकला;
• मार्ग;
• DBMS के साथ काम करें;
• खाका इंजन;
• बहुभाषावाद के लिए समर्थन;
• बहुपरत समर्थन;
• न्यूनतम ओवरहेड।

यह समझने में भी आसान होना चाहिए और एक सुविधाजनक उपकरण होना चाहिए, न कि केवल एक और तकनीक जिसे आगे के अध्ययन की आवश्यकता है।

एपिसोड 2: समुराई का तरीका

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

एपिसोड 3: शानदार बाढ़

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

एपिसोड 4: पहला पत्थर

प्रयोग को दोहराते हुए, मैंने मॉनिटर किया कि सर्वर के साथ क्या हो रहा था और एक समस्या का पता चला - नोड प्रक्रिया सभी उपलब्ध मेमोरी को खा रही थी और या तो कट गई या नीचे लटका दी गई (यह http अनुरोधों को स्वीकार करना बंद कर दिया)। मैं एक आरक्षण करूँगा कि विकास के दौरान मैंने मेमोरी खपत की निगरानी करने की कोशिश की, जैसा कि यह लंबे समय तक चलने वाले अनुप्रयोगों में सबसे खतरनाक क्षणों में से एक है। मैंने अतिरिक्त क्लोजर नहीं किया, वर्ना हार नहीं हुई, सामान्य तौर पर मैंने बड़े करीने से व्यवहार किया। एक बार फिर, अपने कोड के माध्यम से छांटते हुए, मैंने यह सुनिश्चित किया कि त्रुटि इसमें नहीं थी और, स्पष्ट रूप से, परेशान था, क्योंकि इसे वहां ठीक करना सबसे आसान होगा। Node.JS के लिए एक डीबगर मौजूद है , यह काफी सुविधाजनक है, लेकिन अपने असिंक्रोनस ऑपरेशन के कारण Node.JS एप्लिकेशन को डीबग करना अधिक कठिन है। मैं स्वीकार करता हूं कि मैं इस अद्भुत उपकरण के साथ काम करने में 80 के स्तर तक नहीं पहुंच पाया और रिसाव की गणना नहीं कर सका। इसलिए मेरी छुट्टी खत्म हुई। नोड.जेएस की शक्ति सीखने का समय बहुत कम हो गया है, और मैंने इस मामले को बेहतर समय तक स्थगित करने का फैसला किया है। परिणाम से संतुष्ट नहीं, मैंने एक छोटी सी उपयोगिता लिखी जिसने हर दिन प्रक्रिया को फिर से शुरू किया। इस तरह की बैसाखी पर, साइट ने 4-5 महीनों के लिए काम किया। इस बीच, Node.JS का विकास स्थिर नहीं रहा। एक के बाद एक नए संस्करण सामने आए और तीसरे पक्ष के मॉड्यूल भी विकसित हुए, जो बचपन की बीमारियों से छुटकारा दिलाते हैं।

एपिसोड 5: एक नई आशा

और अब, लंबे समय तक ब्रेक के बाद, Node.JS के परिवर्तन लॉग में निश्चित मेमोरी लीक (संस्करण 0.6.6 - 0.6.7) के बारे में प्रविष्टियां थीं। इसके अलावा, संस्करण 0.6.0 से शुरू करके, क्लस्टर एपी को स्थिर रिलीज में शामिल किया गया था, जिसने कई नोड प्रक्रियाओं को शुरू करने के लिए अनावश्यक नृत्य से छुटकारा पाने की अनुमति दी थी। इस सबने उत्साह बढ़ाया और मुझे एक नए कोण से परियोजना पर ध्यान दिया। इस समय तक, मैंने पहले ही देखा है कि मेरे ढांचे के किन हिस्सों का उपयोग नहीं किया गया है, इसमें क्या गायब है, जो सुविधाजनक नहीं है। इसके अलावा, मैंने MongoDB के साथ MySQL (मूल रूप से इसका इस्तेमाल किया गया था) को बदलने का फैसला किया।

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

मॉड्यूलर प्रणाली Node.JS आपको फ्रेमवर्क (रीड - रेडी-मेड मॉड्यूल असेंबली) का उपयोग करने की अनुमति नहीं देता है, लेकिन सीधे मॉड्यूल के साथ काम करने के लिए। उसी समय, अतिरिक्त कार्यक्षमता, ढांचे में लपेटने के बजाय, एक अलग मॉड्यूल में निकालने की आवश्यकता होती है। यह दृष्टिकोण प्रणाली के लचीलेपन को बढ़ाता है और कोड के पुन: उपयोग में सुधार करता है।

इसलिए मुझे परियोजना के लिए एक रिफैक्टिंग योजना मिली। इसमें निम्नलिखित आइटम शामिल थे:

• मॉड्यूल का उपयोग करने से मना करें, मॉड्यूल के सीधे उपयोग पर स्विच करें;
• मेरी समस्या को हल करने के लिए सबसे उपयुक्त मॉड्यूल की एक बड़ी संख्या से चुनें;
• MySQL को MongoDB से बदलें;
• कई प्रक्रियाओं के लॉन्च को व्यवस्थित करने के लिए, नोड उपयोग, अब मूल, क्लस्टर एपीआई ।

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

एपिसोड 6: महाकाव्य मदिरा

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

निष्कर्ष

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

ह्यूस्टन, हमें समस्याएं हैं

-1

Node.JS पर विकसित होने पर पहली चीज जो आपके सामने होगी, वह है एक पूर्ण-IDE की कमी, जो बॉक्स से बाहर काम करती है। बेशक, एक्लिप्स और नेटबीन्स के लिए प्लगइन्स हैं, अन्य आईडीई में आंशिक समर्थन है। लेकिन फिलहाल उन्हें पूर्ण समाधान कहना असंभव है। Cloud9 IDE का बहुत आशाजनक विकास है। यह सीधे ब्राउज़र में जावास्क्रिप्ट विकसित करने के लिए एक आईडीई है। यह IDE तेजी से विकसित हो रहा है और पहले से ही कई Node.JS डेवलपर्स द्वारा सक्रिय रूप से उपयोग किया जाता है, लेकिन साथ ही, मेरे व्यक्तिपरक राय में, यह अभी तक बड़ी परियोजनाओं पर काम करने के लिए तैयार नहीं है, हालांकि छोटे मॉड्यूल लिखने के लिए इसका उपयोग करना बहुत सुविधाजनक है। प्रोजेक्ट पर काम के दौरान, मैंने एक से अधिक IDE बदले। मैंने नोटपैड ++ के साथ शुरुआत की, लंबे समय तक क्लाउड 9 आईडीई का उपयोग किया, दूसरों की कोशिश की, जिनके नाम मुझे अब याद नहीं हैं, लेकिन अंततः नेटबींस में लौट आए। यद्यपि Node.JS API के लिए कोई समर्थन नहीं है, लेकिन वहां शुद्ध जावास्क्रिप्ट के साथ काम करना काफी सुविधाजनक है। जबकि यह इंतजार करना बाकी है और पूर्ण समर्थन की उपस्थिति की उम्मीद है। इस तरह के एक प्लगइन का विकास पहले से ही चल रहा है।

-2

दूसरा अप्रिय क्षण प्रत्येक परिवर्तन करने के बाद आवेदन को फिर से शुरू करने की आवश्यकता होगी। उपयोगिताओं के अस्तित्व के बावजूद जो इस प्रक्रिया को स्वचालित करते हैं, फिर भी ऐसा करने में कुछ समय लगता है। PHP में जितनी जल्दी हो, आप एक बदलाव नहीं कर सकते और तुरंत परिणाम देख सकते हैं। हालांकि, एप्लिकेशन बहुत जल्दी से पुनरारंभ होता है - एक से कई सेकंड तक, उपयोग किए गए मॉड्यूल के आधार पर। इसमें Node.JS निस्संदेह जावा को बेहतर बनाता है - वहाँ एक गंभीर वेब एप्लिकेशन को पुनः आरंभ करने में अधिक समय लगता है।

-3

नौसिखिए Node.JS डेवलपर्स के सामने आने वाली अगली समस्या संभवतः एक स्मृति रिसाव होगी। मेमोरी पर हमेशा और हर जगह निगरानी की जानी चाहिए, लेकिन तेजी से रहने वाले PHP स्क्रिप्ट या छोटे क्लाइंट-साइड जावास्क्रिप्ट बहुत आराम कर रहे हैं। ऐसे अनुप्रयोगों में, कई डेवलपर्स विशेष रूप से कई किलोबाइट मेमोरी के नुकसान को महत्व नहीं देते हैं, और कुछ इस संकेतक की निगरानी बिल्कुल नहीं करते हैं। नोड.जेएस ऐसी रियायतें नहीं देता है। Node.JS पर एप्लिकेशन लंबे समय तक काम करता है, और एक रिसाव के मामले में, साइट के लिए प्रत्येक अनुरोध इसे स्मृति के एक टुकड़े के साथ दूर ले जाएगा जो बहुत जल्दी समाप्त हो जाएगा, जिससे ज्ञात परिणाम होंगे। जावास्क्रिप्ट की विशिष्टता इस प्रकार की त्रुटि को भी प्रोत्साहित करती है। एक बड़े दायरे में एक अतिरिक्त शॉर्ट सर्किट या एक खो गया संस्करण आपको डीबग के अविस्मरणीय घंटे दे सकता है। लेकिन इसमें एक प्लस है - ऐसा अनुभव किसी भी डेवलपर को मेमोरी की सराहना करेगा और अन्य भाषाओं में प्रोग्रामिंग करते समय इसके उपयोग को नियंत्रित करेगा। व्यक्तिगत रूप से, मैं इस सुविधा को माइनस नहीं मानता।

-4

एक और विशेषता जो असुविधाजनक है वह है एसिंक्रोनस कोड से त्रुटि वापसी। तुलना के लिए, PHP में, सभी कोड को समान रूप से निष्पादित किया जाता है, इसलिए आप किसी भी नेस्टिंग स्तर पर एक त्रुटि पकड़ सकते हैं ट्राइ-कैच निर्माण का उपयोग करके। हम इसमें नियंत्रक के काम को लपेट सकते हैं और, एक असाधारण स्थिति की स्थिति में, फेंक दें, और त्रुटि उसके इंतजार में हैंडलर को "पॉप अप" करेगी, जो उपयोगकर्ता को शर्म का एक सुंदर पृष्ठ दिखाएगा। इस तथ्य के बावजूद कि जावास्क्रिप्ट में भी एक ट्राइ-कैच निर्माण है, यह हमारी मदद नहीं करेगा, क्योंकि अधिकांश कोड एसिंक्रोनस रूप से काम करता है (I / O)। इस मामले में, एक नियम के रूप में, असाधारण परिस्थितियां तब नहीं उठती हैं जब एक विधि को बुलाया जाता है, लेकिन जब इसका कॉलबैक काम करता है, जो पहले से ही ट्राइ-कैच निर्माण के बाहर किया जाता है। Node.JS में त्रुटि जानकारी पास करने के लिए, कॉलबैक फ़ंक्शन के पहले पैरामीटर का उपयोग करने के लिए प्रथागत है। यानी यदि हमारे पास कोई त्रुटि है, तो हम कॉलबैक फ़ंक्शन को एक एकल पैरामीटर के साथ कहते हैं जो इसका वर्णन करता है, या हम पहले पैरामीटर को अपरिभाषित / अशक्त करने के लिए सेट करते हैं, और अगले में हम अपनी कार्यक्षमता के परिणाम पास करते हैं। वास्तविक अनुप्रयोगों में, कॉल का घोंसला काफी बड़ा हो सकता है और हर बार त्रुटि को पारित करने के लिए यह बहुत असुविधाजनक है। मेरा मानना ​​है कि एओपी लागू करने से समस्या अभी भी हल हो सकती है, लेकिन यह विषय इस लेख के दायरे से परे है।

-5

सबसे सरल त्रुटियां, जो काफी बार उत्पादन सर्वर को मिलती हैं, आपको परेशान भी करेंगी। कोड के एक बहुत ही कम निष्पादित ब्लॉक में एक चर नाम में एक टाइपो पूरी साइट या क्लोजर एपीआई का उपयोग किया जाता है, तो प्रक्रियाओं में से एक को बंद कर सकता है। इस तरह की परेशानियों से बचने के लिए, आप उपयोगिताओं का उपयोग कर सकते हैं जो एप्लिकेशन की निगरानी करते हैं और यदि आवश्यक हो तो इसे पुनः आरंभ करते हैं, लेकिन असली निन्जा केवल अपने कोड का अच्छी तरह से परीक्षण करते हैं (हालांकि कोई भी तीसरे पक्ष के मॉड्यूल में त्रुटि से सुरक्षित नहीं है)।

-6

आखिरी चीज जो मैं जोड़ना चाहूंगा वह यह है कि जटिल गणितीय गणना Node.JS के लिए नहीं है। इस विषय पर, हब में पहले से ही बहुत ज्वलंत विषय था और इसमें लिखी गई हर चीज को दोहराने का कोई मतलब नहीं है और मुझे इस पर टिप्पणी नहीं दिखती है। मैं केवल यह कह सकता हूं कि विषय के लेखक (निश्चित रूप से, मेरा मतलब मूल के लेखक से है, अनुवाद से नहीं) तकनीक के विकल्प के साथ समस्याएं हैं, या यह सिर्फ एक ट्रोल है। Node.JS में, इवेंट लूप के कई मोड़ पर किए गए छोटे पुनरावृत्तियों में कार्य को विभाजित करके जटिल गणितीय गणना करना अभी भी संभव है, लेकिन यह पहले से ही विकृत और कट्टरता है। इस तरह के कार्यों को इवेंट लूप के दायरे से बाहर निकालना बहुत आसान है या यहां तक ​​कि विकास के लिए एक और तकनीक का चयन करना है।

यह सब किस लिए है?

यदि इस समय तक आपके पास ऐसा कोई सवाल नहीं था, तो आप या तो एक अनुभवी जावास्क्रिप्ट डेवलपर हैं, या एक खोज रोबोट, या चक नॉरिस (हैलो चक!)। बाकी सभी के लिए, मैं उन लाभों का वर्णन करने की कोशिश करूंगा जो एनओडी.जेएस पर एक वेब परियोजना का विकास हमें देता है।

+1

Node.JS का सबसे महत्वपूर्ण लाभ मैं अतुल्यकालिक इनपुट / आउटपुट और इसके साथ काम की पारदर्शिता पर विचार करता हूं। अधिकांश वेब परियोजनाओं में, सबसे आम संचालन डेटाबेस से डेटा पढ़ रहे हैं और इसे बचा रहे हैं। समान संचालन आमतौर पर सबसे धीमे होते हैं। लेकिन हमेशा दूर से वे एक दूसरे पर निर्भर करते हैं, इसके विपरीत, ज्यादातर मामलों में वे परमाणु हैं। उदाहरण के लिए, एक लेख में एक नई टिप्पणी जोड़ते समय, हमें इसकी आवश्यकता है:

• टिप्पणी स्वयं सहेजें;
• उपयोगकर्ता को ताज़ा करें (उदाहरण के लिए, उपयोगकर्ता टिप्पणियों की संख्या और उसकी अंतिम टिप्पणी की तारीख);
• एक लेख को ताज़ा करें (उपयोगकर्ता को अपडेट करने के समान);
• क्वेरी परिणाम लॉग करें।

ये सभी ऑपरेशन एक दूसरे से स्वतंत्र हैं और DBMS उन्हें एक साथ प्रदर्शन करने में सक्षम है। जब तुल्यकालन निष्पादित किया जाता है, उदाहरण के लिए PHP में, इन कार्यों को क्रमिक रूप से एक के बाद एक किया जाएगा, हर बार पिछले एक के पूरा होने की प्रतीक्षा में। Node.JS में, हमारे पास इन सभी अनुरोधों को DBMS में "समानांतर में" भेजने का अवसर है। वास्तव में, अनुरोध अभी भी क्रमिक रूप से भेजे जाते हैं (इसलिए मैंने "उद्धरण में" समानांतर में "शब्द उद्धृत किया है"), क्योंकि Node.JS एक प्रक्रिया में काम करता है। लेकिन Node.JS अगले एक को भेजने के पिछले अनुरोध के परिणाम की प्रतीक्षा नहीं करता है। अनुरोध भेजने का समय, इसके संचालन के समय की तुलना में, उपेक्षित किया जा सकता है। जब अनुरोध निष्पादित होते हैं, तो कॉलबैक फ़ंक्शन को उनके परिणाम को संसाधित करने के लिए कहा जाएगा। ये कॉल क्रमिक रूप से अनुरोध भेजने के रूप में होंगे, और उनके परिणाम उनके निष्पादन समय की तुलना में अतुलनीय रूप से तेजी से संसाधित होंगे। इस प्रकार, डेटा के साथ काम करने का कुल समय सबसे लंबे अनुरोध के कामकाजी समय के बराबर होगा + अनुरोध भेजने और उनके परिणामों को संसाधित करने के लिए एक छोटा सा ओवरहेड। लेकिन किसी भी मामले में, यह उनके अनुक्रमिक प्रसंस्करण के दौरान सभी अनुरोधों के निष्पादन समय के योग से तेज होगा (अनुरोध भेजने और इस मामले में उनके परिणामों को संसाधित करने के लिए ओवरहेड भी कहीं नहीं जाता है)।

+2

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

+3

तीसरा सकारात्मक कारक यह है कि सर्वर पर और क्लाइंट पर हमारी एक ही भाषा है, यह हमें कुछ कोड (फॉर्म सत्यापन, क्लाइंट पर टेम्पलेट बनाने आदि) का पुन: उपयोग करने की अनुमति देता है। और सामान्य तौर पर, यह विकास को बहुत सरल करता है, खासकर जब एप्लिकेशन का क्लाइंट हिस्सा जटिल होता है और बटन पर घटनाओं के एक जोड़े को संसाधित करने के बजाय गंभीर काम की आवश्यकता होती है।

4

Node.JS प्रक्रिया लंबे समय तक रहती है और सभी HTTP अनुरोधों को आंतरिक रूप से संसाधित करती है। इसका मतलब यह है कि प्रत्येक नए अनुरोध के लिए आरंभीकरण नहीं किया जाता है, उदाहरण के लिए, PHP में। सेटिंग्स भरी हुई हैं, डेटाबेस और कैश के कनेक्शन खुले हैं, कोड संकलित किया गया है और जाने के लिए तैयार है। इस वास्तुकला और लचीलेपन के लिए धन्यवाद, जावास्क्रिप्ट विभिन्न अनुकूलन तकनीकों के लिए एक विशाल गुंजाइश प्रदान करता है। उदाहरण के लिए, एक बार जब आप किसी टेम्प्लेट की जांच कर लेते हैं, तो आप इसे एक फ़ंक्शन के रूप में संग्रहीत कर सकते हैं जो डेटा को इनपुट के रूप में स्वीकार करता है और तैयार किए गए HTML को वापस करता है। या आप आसानी से सबसे अधिक उपयोग किए जाने वाले डेटा के कैशिंग (प्रक्रिया के लिए) को आसानी से व्यवस्थित कर सकते हैं, जो मेमकेड की तुलना में उनके साथ काम करने की गति में भी वृद्धि देगा। हां, PHP के लिए ऐसे समाधान हैं जो प्रारंभिक प्रक्रिया को आंशिक रूप से तेज करते हैं - APC के लिए APC, FastCGI में लगातार कनेक्शन के लिए समर्थन, आदि। लेकिन जब सिद्धांत में इसकी अनुपस्थिति के साथ त्वरित प्रारंभ प्रक्रिया की तुलना करते हैं, तो लाभ हमेशा बाद के लिए होगा।

5

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

+6

जावास्क्रिप्ट भाषा ही और Node.JS एपीआई बहुत लचीली और संक्षिप्त हैं। कार्यक्रम कॉम्पैक्ट और पढ़ने में आसान हैं। आप उन में कक्षाएं देखने की संभावना नहीं रखते हैं, जिनमें लगभग पूरी तरह से गेटर्स और सेटर शामिल हैं, या दर्जनों फाइलें इंटरफेस के विवरण के साथ हैं। क्लोजर और लैम्ब्डा फ़ंक्शन जैसी चीजें आपको बहुत सुंदर कोड लिखने की अनुमति देती हैं, लेकिन डेवलपर की एक विशेष प्रतिभा के साथ, वे इसे नरक की एक शाखा में बदल सकते हैं।
जावा और नोड.जेएस के प्रदर्शन की तुलना देखने के बाद मैं लंबे समय तक हंसता रहा। यहां आप लंबे समय तक विभिन्न तर्क दे सकते हैं और तर्क दे सकते हैं, लेकिन जैसा मैं सोचता हूं वैसा ही कहूंगा।इवेंट लूप में, मैंने इस प्रदर्शन को मोड़ दिया, यदि उसी समय प्रोग्राम कोड में दसियों बार वृद्धि हुई। मेरे पास जावा + स्प्रिंग फ्रेमवर्क + हाइबरनेट में एक बड़ी WEB परियोजना विकसित करने का अनुभव है। कोड की 10 लाइनें हैं जो अच्छी तरह से वर्णन करती हैं कि 11 वीं क्या करेगी। यह असभ्य है, लेकिन यह लगभग स्थिति को दर्शाता है। शायद कार्यों के कुछ वर्ग के लिए यह प्रासंगिक है, लेकिन औसत वेब-परियोजनाओं के लिए नहीं। यह जोड़ने योग्य है कि "हैलो दुनिया" पर इस तरह की तुलना वास्तविक स्थिति को प्रतिबिंबित नहीं करती है। अनुप्रयोग तर्क की उपस्थिति के साथ, डेटाबेस, कैशिंग और सिस्टम के अन्य घटकों के साथ काम करते हुए, इसकी अपूर्णता के कारण तकनीक के इष्टतम उपयोग नहीं होने के कारण ब्रेक पकड़ने की संभावना बहुत बढ़ जाती है। इसके अलावा, आपको यह याद रखना होगा कि सर्वर संसाधन दो मामलों में पर्याप्त नहीं हो सकते हैं:

• कोड खराब लिखा गया है;
• आपकी साइट पर बहुत बड़ा ट्रैफ़िक है।

पहले मामले में, कोड और प्रौद्योगिकी के बाद के पुनर्लेखन के साथ केवल अपने हाथों को सीधा करने से इसका कोई लेना-देना नहीं होगा। दूसरे में - आपके पास पहले से ही एक और सर्वर खरीदने के लिए पर्याप्त पैसा है, क्योंकि दर्जनों गुना अधिक कोड का समर्थन करने की तुलना में यह आर्थिक रूप से अधिक लाभदायक है।

निष्कर्ष

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

जारी रखा जाए

दूसरे भाग में, मैं अधिक विस्तार से एप्लिकेशन आर्किटेक्चर पर ध्यान केंद्रित करूंगा। मैं आपको बताऊंगा कि मैंने कौन से मॉड्यूल का उपयोग किया और उनके बीच बातचीत कैसे व्यवस्थित है।

इसे पढ़ने वाले सभी को धन्यवाद। मुझे टिप्पणियों में आपकी प्रतिक्रिया और राय देखकर खुशी होगी।