अक्सर मुझे ऐसे सवाल आते हैं जैसे: "और बड़ी / प्रसिद्ध / उल्लेखनीय आईटी कंपनियों में से कौन आमतौर पर उत्पादन में Node.js का उपयोग करता है?" 19 जनवरी, 2012 को कुख्यात जोएल स्पोलस्की द्वारा स्थापित कंपनी फॉग क्रीक के ब्लॉग पर "द ट्रेलो टेक स्टैक" लेख प्रकाशित किया गया था। यह अजीब है कि हेबर पर यह किसी भी तरह से नजरअंदाज कर दिया। इसलिए, इस कमी को ठीक करने के लिए, और एक बड़ी परियोजना में Node.js का उपयोग करने का एक उदाहरण दिखाने के लिए उसी समय, मैंने इस लेख का अनुवाद किया।

लेख अपने आप में काफी बड़ा है, इसलिए इसे दो भागों में बांटा गया है:

भाग 1

• CoffeeScript
• ग्राहक
  * बैकबोन.जेएस
  * एचटीएमएल 5 इतिहास एपीआई
  * मूंछें
• मतदान और मतदान
  * सॉकेट
  * AJAX अनुरोध करता है

भाग २

• सर्वर
  * नोड.जेएस
  * HAProxy
  * रेडिस
  * MongoDB
• तो क्या हम इसे पसंद करते हैं?

ट्रेलो तकनीक स्टैक

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


ट्रेलो का प्रारंभिक लेआउट।

लेआउट ने हमें एक पृष्ठ के वेब एप्लिकेशन पर ले जाया, जो क्लाइंट-साइड यूजर इंटरफेस बनाता है और उत्तर में डेटा अपडेट प्राप्त करता है। यह उस काम से काफी अलग था जो हमने पहले फॉग क्रीक में किया था। इसलिए, एक तकनीकी दृष्टिकोण से, ट्रेलो का विकास एक साहसिक कार्य था।

सबसे पहले, इसने हमें आश्चर्यचकित कर दिया कि [एप्लिकेशन] की संरचना कितनी दिलचस्प और विविधतापूर्ण हो सकती है, इससे पहले कि [प्रोजेक्ट] प्रबंधन चिंतित हो जाए, जोएल के साथ प्रारंभिक बैठक में हमारी समस्याएं हल हो गईं, जब उन्होंने कहा: "समाधान का उपयोग करें जो पूरी तरह से दो साल तक काम करेगा। "।

तो हमने किया। हमने लगातार होनहार (और अक्सर समस्याग्रस्त) प्रौद्योगिकियों का चयन किया है जो अधिक परिपक्व विकल्पों की तुलना में एक अद्भुत अनुभव प्रदान करेंगे। हम लगभग एक साल से ऐसा कर रहे हैं, और हम इसे पसंद करते हैं।

CoffeeScript

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

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

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

ग्राहक

• Backbone.js (MVC फ्रेमवर्क)
• HTML 5 (इतिहास API: pushState)
• मूंछें (टेम्प्लेट)

Trello सर्वर, संक्षेप में, HTML के साथ काम नहीं करते हैं। वास्तव में, वे ज्यादा क्लाइंट कोड निष्पादित नहीं करते हैं। ट्रेलो पेज एक हल्का (2KiB) पतला खोल है जो क्लाइंट एप्लिकेशन को सर्वर से एक न्यूनतम और संकुचित जेएस फाइल (थर्ड-पार्टी लाइब्रेरी और हमारी संकलित कॉफीस्क्रिप्ट फाइल और मूंछ टेम्प्लेट सहित) और एक सीएसएस फाइल (हमारे द्वारा संकलित) के रूप में डाउनलोड करता है। कम फ़ाइलें और एम्बेडेड (इनलाइन) छवियों सहित। यह सब कुछ 250KiB से कम है, और हम इसे Amazon के CloudFront CDN के साथ साझा कर रहे हैं। इस तरह से हम अधिकांश उपयोगकर्ताओं के लिए कम विलंबता डाउनलोड प्राप्त करते हैं। काफी हाई-स्पीड कनेक्शन (हाई-बैंडविड्थ) के मामले में हमें ब्राउज़र विंडो में एप्लिकेशन का डाउनलोड और लॉन्च लगभग आधा सेकंड में मिलता है। हम कैशिंग से भी लाभान्वित होते हैं, और इसलिए ट्रेलो की बाद की यात्राओं में वह हिस्सा [डाउनलोड] छोड़ दिया जाता है।

उसी समय, हमने शुरुआत पृष्ठ से AJAX के माध्यम से डेटा लोडिंग को हटा दिया और सर्वर पर एक WebSocket कनेक्शन स्थापित करने का प्रयास कर रहे हैं।

Backbone.js

जब डेटा के साथ प्रतिक्रिया आती है, तो Backbone.js अभिनय शुरू करता है। Backbone के साथ विचार सर्वर से प्राप्त प्रत्येक मॉडल को (देखें) का उपयोग करके प्रदर्शित करना है, और Backbone निम्नलिखित के आसान तरीके प्रदान करता है:

• HTML में DOM ईवेंट को ट्रैक करना जो व्यू द्वारा बनाया गया था और उन्हें सर्वर के साथ सिंक्रनाइज़ होने वाले मॉडल में हैंडलर के लिए बाध्य करता है;
• ट्रैकिंग मॉडल परिवर्तन और परिवर्तित HTML ब्लॉक प्रदर्शित करना।

शान से! इस दृष्टिकोण का उपयोग करके, हमें एक सामान्य, समझने योग्य और समर्थित क्लाइंट एप्लिकेशन मिलता है। हम विशेष रूप से अपडेट को संभालने और मॉडल के क्लाइंट-साइड पुन: उपयोग को सरल बनाने के लिए क्लाइंट-साइड मॉडल कैश का निर्माण करते हैं।

History.pushState

अब जब हमारे पास ब्राउज़र विंडो में संपूर्ण क्लाइंट एप्लिकेशन लोड है, तो हम पृष्ठों के बीच नेविगेट करने में समय बर्बाद नहीं करना चाहते हैं। हम पृष्ठों के बीच नेविगेट करने के लिए HTML 5 History.pushState इंटरफ़ेस विधि का उपयोग करते हैं। इस तरह, हम स्थान बार [ब्राउज़र तत्व] में सही और सुसंगत लिंक प्रदान करते हैं, और संक्रमण के बाद हम केवल डेटा लोड करते हैं और इसे बैकबोन के आधार पर उपयुक्त नियंत्रक को पास करते हैं।

मूंछ

HTML में अपने मॉडल प्रदर्शित करने के लिए, हम मूंछों का उपयोग करते हैं - तार्किक निर्माणों के न्यूनतम उपयोग के साथ एक टेम्पलेट भाषा। जबकि "[substitute_ here_your_name] टेम्प्लेट की पूरी शक्ति का उपयोग" अच्छा लगता है, व्यवहार में यह पता चलता है कि स्पष्ट कोड बनाए रखने के लिए डेवलपर्स से गंभीर अनुशासन की आवश्यकता होती है। हम मूंछ के "प्रतिभा प्रतिभा की बहन है" दृष्टिकोण से बहुत खुश थे, जो हमें ग्राहक तर्क के साथ मिश्रण किए बिना टेम्पलेट कोड का पुन: उपयोग करने की अनुमति देता है और भ्रम पैदा करता है।

मतदान और मतदान

वास्तविक समय के अपडेट नए नहीं हैं, लेकिन एक सहयोग उपकरण बनाते समय वे एक महत्वपूर्ण हिस्सा हैं, इसलिए हमने कुछ समय ट्रेलो के इस हिस्से पर बिताया।

सॉकेट.आईओ और वेबसॉकेट्स

उन ब्राउज़र के लिए जो इसका समर्थन करते हैं, हमने WebSocket कनेक्शन का उपयोग किया, ताकि सर्वर अन्य लोगों द्वारा संबंधित चैनलों को सुनने वाले ब्राउज़र द्वारा किए गए परिवर्तनों को धक्का दे। हम संशोधित (*) सॉकेट.आईओ क्लाइंट और सर्वर लाइब्रेरी का उपयोग करते हैं जो हमें सीपीयू और मेमोरी उपयोग के संदर्भ में न्यूनतम लागत के साथ हमारे प्रत्येक सर्वर पर कई हजारों वेबसैट कनेक्शन खोलने की अनुमति देता है। इस प्रकार, जब बोर्ड पर कुछ कार्रवाई होती है [ट्रोलो तत्व] जिसे आप देख रहे हैं, यह क्रिया हमारे सर्वर पर प्रक्रिया में स्थानांतरित हो जाती है और ब्राउज़र को न्यूनतम विलंब के साथ वितरित की जाती है, आमतौर पर एक सेकंड से बहुत कम।

(*) वर्तमान में, सॉकेट.आईओ सर्वर को कुछ प्रक्रियाओं और रेडिस स्टोरेज का उपयोग करते समय क्लाइंट के साथ 10K से अधिक कनेक्शन प्राप्त करने में कुछ समस्याएं हैं। और क्लाइंट के पास कुछ समस्याएं हैं जो एक ही सर्वर पर कई कनेक्शन खोलने या इस तथ्य को जन्म दे सकती हैं कि ग्राहक यह निर्धारित नहीं कर पाएगा कि इसका कनेक्शन सेवा में है। हमारे परिवर्तन करने के साथ कुछ समस्याएं हैं (हैक्स!) परियोजना पर वापस लौटें - कई मामलों में वे केवल वेबस्केट्स के साथ काम करते हैं (एकमात्र सॉकेट.आई ट्रांसपोर्ट जो हम उपयोग करते हैं)। हम उन बदलावों पर काम कर रहे हैं जो परियोजना में वापस लाने के लिए सामान्य उपयोग के लिए उपयुक्त हैं।

AJAX अनुरोध करता है

वे जटिल नहीं हैं, लेकिन वे काम करते हैं।


आर्किटेक्चर का शुरुआती स्केच।

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

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

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

जारी रखने के लिए ...