कोणीय बनाम डर्बी। केवल एक ही होना चाहिए

इतना बड़ा नाम बताता है कि आज हम MVC अवधारणा की तुलना क्लाइंट (Angular, Ember, Backbone, Marionette, Knockout, इत्यादि हजारों) से करते हैं, जो Full-Stack अवधारणा (Derby, Meteor) के साथ है। हम पेशेवरों, विपक्ष, मिथकों, त्रुटियों का विश्लेषण करेंगे।

मामले के इतिहास

एक बार, जब एमवीसी वेब डेवलपर्स के दिमाग में लोकप्रिय होने लगा था, यह सर्वर पर था। Django, रूबी ऑन रेल्स, एस्प नेट MVC, Yii सर्वर पर महान MVC के उदाहरण हैं। सभी ने अपनी भाषा को अपनी पसंद के अनुसार चुना, स्थैतिक पृष्ठों ने तार पर उड़ान भरी, jQuery - ओह, यह एक अद्भुत समय था। थंडर अचानक मारा। यह पता चला कि उपयोगकर्ता पुनः लोड करने के लिए पूरे पृष्ठ के लिए प्रत्येक क्लिक के बाद इंतजार नहीं करना चाहते हैं, लेकिन चाहते हैं कि वेब नियमित कार्यक्रमों के साथ काम करना अधिक पसंद करे - इंटरैक्टिव। पहली नज़र में, jQuery + Ajax इस समस्या को हल कर सकता है, लेकिन जैसे ही वेब डेवलपर्स ब्राउज़र में असंरचित कोड में डूबने लगे, यह स्पष्ट हो गया कि अधिक मूलभूत परिवर्तनों की आवश्यकता थी।

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

समस्याओं

समस्याओं में चलने वाले पहले ट्विटर थे। सामान्य तौर पर, वे पूरे रास्ते गए। हमने रूबी ऑन रेल्स के साथ शुरुआत की और सर्वर पर HTML उत्पन्न किया, फिर क्लाइंट पर MVC पर सब कुछ फिर से लिखा और कुछ समय में महसूस किया कि उपयोगकर्ता पाठ के 140 वर्णों को पढ़ने के लिए 4 सेकंड इंतजार करता है। अब वे Scala का उपयोग कर सर्वर पर HTML का हिस्सा उत्पन्न करते हैं, और क्लाइंट पर जावास्क्रिप्ट का उपयोग करके भाग बनाते हैं। Google ऐसा करता है, वे C ++ का उपयोग कर सर्वर पर और जावास्क्रिप्ट का उपयोग कर क्लाइंट पर html उत्पन्न करते हैं। ऐसी वास्तुकला को बनाए रखना मुश्किल है और छोटी कंपनियों और स्टार्टअप्स के लिए उपलब्ध नहीं है।

सर्च इंजन जावास्क्रिप्ट से सर्वर से html प्राप्त करने की अधिक संभावना है। कभी-कभी वे उपयोगकर्ताओं के लिए क्लाइंट पर MVC के अलावा विशेष रूप से खोज इंजन के लिए सर्वर पर HTML उत्पन्न करके समस्या को हल करने का प्रयास करते हैं। अन्य लोग एमवीसी के पक्ष में क्लाइंट पर एमवीसी छोड़ देते हैं, एसईओ के लिए अन्तरक्रियाशीलता का त्याग करते हैं।

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

बदली करने योग्य बैकएंड

क्लाइंट पर एमवीसी के लिए मुख्य तर्क में से एक बैकएंड को आसानी से बदलने की क्षमता है। बैकएंड को बदलना बहुत आसान प्रक्रिया नहीं है, क्योंकि क्लाइंट पर MVC मानता है कि सर्वर में कम से कम REST-api, सत्यापन, डेटा के साथ काम करना, प्राधिकरण है। वास्तविक जीवन में, बैकएंड लगभग कभी नहीं बदलता है।

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

Node.js

Node.js के बारे में मुख्य मिथक यह है कि यह स्थिर नहीं है और अनुरोध कभी-कभी खो जाते हैं। क्लस्टर और डोमेन के आगमन के साथ , यह अब प्रासंगिक नहीं है।

एक और मिथक है नोड.जेएस धीमा है। यहाँ, एक कह सकता है कि v8 C से केवल 3-5 गुना धीमा है या कि Node.js कनेक्शन को बनाए रखने के लिए केवल 8 kb मेमोरी खर्च करता है। लेकिन शायद एक सर्वर पर एक साथ लाखों कनेक्शन पर्याप्त तर्क होंगे।

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

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

पूरा ढेर

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

दूसरा मिथक यह है कि फुल-स्टैक फ्रेमवर्क बहुत जटिल हैं और केवल बड़ी परियोजनाओं के लिए उपयुक्त हैं। डर्बी का उपयोग स्टैटिक साइट्स के लिए किया जा सकता है, जिसमें बिना डेटाबेस के मल्टीप्लेयर गेम्स और बड़े इंटरेक्टिव एप्लिकेशन की तरह ही सफलता मिलती है।

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

चौथा मिथक यह है कि फुल-स्टैक फ्रेमवर्क अभी भी कच्चे हैं, स्थिर नहीं हैं, वे डेटा को सिंक्रनाइज़ करते समय प्रदर्शन समस्याओं का अनुभव करते हैं। फिलहाल उत्पादन में कई परियोजनाएं हैं जो लोड के अधीन हैं। कोई समस्या नहीं हैं।

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

डर्बी सामग्री