स्टार्टअप या उत्पादन पर समस्याओं के लिए Node.JS

शुभ दिन। मैं एक लाइव प्रोजेक्ट पर Node.JS का उपयोग करने के अपने अनुभव के बारे में हबर-समुदाय के साथ साझा करना चाहूंगा। पांच महीने पहले, मैंने अपने पुराने विचारों में से एक को लागू करना शुरू कर दिया - उपलब्धियों की सेवा।

परियोजनाओं को विकसित करते समय, मैं इस दृष्टिकोण का पालन करना पसंद करता हूं कि प्रौद्योगिकी का विकल्प इसके उपयोग की कम लागत से उचित होना चाहिए। इसलिए, मेरी परियोजना के लिए, मैंने स्टैक को चुना - Node.JS + mongoDB, क्योंकि ये ऐसी तकनीकें हैं जिन्हें मैं सबसे अच्छा जानता हूं।


मैं यह नोट करना चाहता हूं कि यहां मैं केवल उन समस्याओं का वर्णन करूंगा जो मैंने खुद का सामना किया था।

मजबूर अतुल्यकालिक

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

db.collection('table', function(err, collection) { collection.findOne({uid:uid}, function(err, doc) { cb(doc); }); }); 

इस प्रकार, ऊपर वर्णित कार्य, एक कॉल कॉल को कम करता है:

 db.collection('table', function(err, collection) { collection.findOne({uid:uid}, function(err, doc) { db.collection('table2', function(err, collection) { collection.findOne({size:doc.size}, function(err, doc) { cb(doc); }); }); }); }); 

यह Coffescript या Async मॉड्यूल का उपयोग करके ऐसी समस्याओं को हल करने के लिए प्रथागत है, दोनों कोड को अधिक पठनीय और पर्याप्त बनाते हैं। एक मध्यवर्ती समाधान के रूप में, मैंने कॉल को फ़ंक्शन में विभाजित किया - यह विकल्प कोड को अधिक या कम ऊर्ध्वाधर रूप में लाता है, लेकिन यह भी, कॉल की एक लंबी श्रृंखला के साथ, यह इस बहुत ही श्रृंखला में ट्रैकिंग त्रुटियों की समस्या पैदा करता है।

डिबगिंग

सामान्य कार्यों में Node.JS में क्रैश होने से कोई शिकायत नहीं होती है, लेकिन कभी-कभी ऐसे निष्पादन होते हैं, जिन पर यह स्पष्ट नहीं होता है कि त्रुटि क्या है, केवल यह स्पष्ट है।

 events.js:71 throw arguments[1]; // Unhandled 'error' event ^ Error: socket hang up at createHangUpError (http.js:1264:15) at Socket.socketOnEnd [as onend] (http.js:1352:23) at TCP.onread (net.js:419:26) 

इस लॉग द्वारा यह स्पष्ट है कि http मॉड्यूल को कॉल करने में त्रुटि। और अगर एप्लिकेशन में एक से अधिक http कॉल है? त्रुटि के कारण कौन सा स्पष्ट नहीं है। आपको दूसरी तरफ लॉग को देखना होगा।

सदैव

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

कैचिंग एरर

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

शायद यही सब है। यह ध्यान देने योग्य है कि यद्यपि मैंने केवल Node.JS के नकारात्मक पहलुओं का वर्णन किया है जो मुझे पता चला, लेकिन मेरे लिए और भी सकारात्मक पहलू हैं) आप सभी का ध्यान देने के लिए धन्यवाद)

पुनश्च यदि किसी को इस परियोजना के लिंक में रुचि है प्रोफ़ाइल में है।