आधुनिक रेल के साथ खरगोश होल एसपीए से बाहर निकलना

टीएल; डीआर: एसपीए निशान अंधेरा और भयावहता से भरा है। आप निडर होकर उनका मुकाबला कर सकते हैं ... या कोई दूसरा रास्ता चुनें जो आपको सही जगह ले जाए: आधुनिक रेल।



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

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

खरगोश छेद एसपीए

एक पृष्ठ का एक आवेदन एक जावास्क्रिप्ट अनुप्रयोग है, जिसे एक बार डाउनलोड करने के बाद, पृष्ठ को फिर से लोड किए बिना पूर्ण नियंत्रण प्राप्त होता है: प्रतिपादन, सर्वर से डेटा प्राप्त करना, उपयोगकर्ता इंटरैक्शन को संसाधित करना, स्क्रीन अपडेट करना ...

ऐसे एप्लिकेशन पारंपरिक वेब पृष्ठों की तुलना में अधिक मूल लगते हैं, जहां एप्लिकेशन सर्वर पर निर्भर करता है। उदाहरण के लिए, यदि आप ट्रेलो का उपयोग करते हैं, तो आप नोटिस कर सकते हैं कि कार्ड कितनी जल्दी बनते हैं।

बेशक, बड़ी जिम्मेदारी बड़ी ताकत के साथ आती है। पारंपरिक वेब अनुप्रयोगों में, आपके सर्वर एप्लिकेशन में एक डोमेन मॉडल और व्यावसायिक नियम, एक डेटाबेस के साथ काम करने के लिए डेटा एक्सेस तकनीक, और एचटीएमएल पेज HTTP अनुरोधों के जवाब में HTML पेज कैसे इकट्ठे होते हैं, इसे नियंत्रित करने के लिए एक नियंत्रक परत शामिल है।

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

सर्वर के लिए:

• एक एपीआई जो आपके ग्राहक की डेटा जरूरतों को पूरा करता है
• क्लाइंट के साथ डेटा के आदान-प्रदान के लिए एक JSON सीरियलाइज़ेशन सिस्टम और एक कैशिंग सिस्टम जो इस का समर्थन करता है

नए जावास्क्रिप्ट क्लाइंट के लिए:

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

संक्षेप में, एसपीए के साथ आपके पास समर्थन के लिए एक और आवेदन होगा। और हल करने के लिए समस्याओं का एक नया सेट। और ध्यान दें, आप एक अनुप्रयोग को दूसरे के साथ प्रतिस्थापित नहीं कर सकते। आपको अभी भी सर्वर एप्लिकेशन की आवश्यकता है (अब यह HTML के बजाय JSON प्रदान करेगा)।

यदि आपने एसपीए के साथ कभी काम नहीं किया है, तो आप उन कठिनाइयों को कम कर सकते हैं जो आपके सामने आएंगी। मैं यह जानता हूं क्योंकि मैंने अतीत में वही गलतियां की थीं। रेंडर JSON? मैं इसे संभाल सकता हूं। जावास्क्रिप्ट में एक अमीर डोमेन ऑब्जेक्ट मॉडल? यह अजीब लगता है। और, आप जानते हैं, यह ढांचा इन सभी समस्याओं का समाधान करेगा। बढ़िया केक!

झूठी।

एपीआई और डेटा विनिमय।

आपके नए एप्लिकेशन और सर्वर के बीच संचार एक जटिल मुद्दा है।

दो विरोधी ताकतें हैं:

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

इसके अलावा, आपको यह सोचने की ज़रूरत है कि क्या डाउनलोड करना है, और उन्हें अपनी प्रत्येक स्क्रीन के लिए कब करना है। मेरा मतलब है, आपको बूटस्ट्रैप के बीच एक संतुलन की आवश्यकता है, जो आपको तुरंत चाहिए और जिसे आलसी लोड किया जा सकता है, और एक एपीआई विकसित करना जो आपको ऐसा करने की अनुमति देता है।

कुछ मानक यहां मदद कर सकते हैं। JSON एपीआई मानकीकृत JSON प्रारूप; या ग्राफक्लाइन, केवल आवश्यक डेटा का चयन करने के लिए, एक क्वेरी में आवश्यक के रूप में जटिल। लेकिन उनमें से एक भी आपको इससे नहीं बचाएगा:

• प्रत्येक डेटा एक्सचेंज का विस्तार
• सर्वर पर कुशलता से डेटा का चयन करने के लिए प्रश्नों को लागू करना

और ये दोनों पहलू पर्याप्त मात्रा में अतिरिक्त कार्य का प्रतिनिधित्व करते हैं।

बूट समय

लोगों को एसपीए को गति के साथ जोड़ने के लिए उपयोग किया जाता है, लेकिन सच्चाई यह है कि उन्हें तेजी से लोड करने के लिए प्राप्त करना इतना आसान नहीं है। इसके कई कारण हैं:

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

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

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

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

इस दृष्टिकोण को सर्वर पर जावास्क्रिप्ट रनटाइम चलाने की आवश्यकता होती है, और यह तकनीकी समस्याओं के बिना भी नहीं है। उदाहरण के लिए, डेवलपर्स को लोडिंग प्रक्रिया में परिवर्तन के रूप में एसपीए लोडिंग घटनाओं पर विचार करना चाहिए।

मुझे इस विचार में कोड का पुन: उपयोग करने का अवसर पसंद है, लेकिन मैंने एक कार्यान्वयन नहीं देखा है जो मुझे विपरीत दिशा में जाने की अनुमति देगा। इसके अलावा, यह पेज रेंडरिंग प्रक्रिया मेरे लिए बहुत मज़ेदार है:

- सर्वर: सर्वर एपीआई के लिए अनुरोध
- सर्वर: डेटाबेस क्वेरी
- सर्वर: JSON उत्पन्न करते हैं
- सर्वर: JSON को HTML में बदलें
- क्लाइंट: प्रारंभिक HTML प्रदर्शित करें
- क्लाइंट: एसपीए डाउनलोड करें
- क्लाइंट: प्रारंभिक HTML को पार्स करें और DOM इवेंट को सब्सक्राइब करें

क्या आप केवल डेटाबेस से डेटा का अनुरोध कर सकते हैं, HTML उत्पन्न कर सकते हैं और काम करना शुरू कर सकते हैं?

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

आर्किटेक्चर

एक समृद्ध उपयोगकर्ता इंटरफ़ेस के साथ एप्लिकेशन विकसित करना मुश्किल है। यह सब इसलिए है क्योंकि यह उन समस्याओं में से एक है जो एक वस्तु-उन्मुख दृष्टिकोण और कई डिजाइन पैटर्न के उद्भव के लिए प्रेरित करते हैं।

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

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

एसपीए ढांचे के रूप में कई अलग-अलग आर्किटेक्चर हैं:

• अधिकांश रूपरेखा पारंपरिक MVC टेम्पलेट से भिन्न होती हैं। एम्बर शुरुआत में कोको एमवीसी से प्रेरित था, लेकिन हाल के संस्करणों में इसके प्रोग्रामिंग मॉडल को काफी बदल दिया।
• एक प्रवृत्ति है कि डेवलपर्स नियंत्रक और प्रस्तुति के पारंपरिक अलगाव के बजाय घटकों को पसंद करते हैं (कुछ रूपरेखाएं, जैसे कि एम्बर और कोणीय, हाल के संस्करणों में इस दृष्टिकोण में चले गए हैं)। सभी चौखटे किसी न किसी तरह के डेटा बाइंडिंग को लागू करते हैं। दोहरे पक्षीय बंधन को साइड इफेक्ट्स के कारण हतोत्साहित किया जाता है जो इसमें योगदान दे सकते हैं।
• अधिकांश चौखटे में एक राउटिंग सिस्टम शामिल होता है जो आपको URL और स्क्रीन को मैप करने की अनुमति देता है, और यह निर्धारित करता है कि रेंडरिंग के लिए घटकों को तत्काल कैसे करें यह एक अद्वितीय वेब दृष्टिकोण है जो पारंपरिक डेस्कटॉप इंटरफेस पर मौजूद नहीं है।
• अधिकांश फ्रेमवर्क HTML कोड को जावास्क्रिप्ट कोड से अलग करते हैं, लेकिन रिएक्ट HTML-पीढ़ी और जावास्क्रिप्ट को मिलाता है और इसका व्यापक उपयोग करते हुए इसे काफी सफलतापूर्वक करता है। जावास्क्रिप्ट में सीएसएस एम्बेड करने के आसपास एक प्रचार भी है। फ़्लक्स आर्किटेक्चर के साथ, फेसबुक ने उद्योग को बहुत प्रभावित किया है, और Redux, vuex, आदि जैसे कंटेनर इससे बहुत प्रभावित हैं।

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

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

अंत में, मैं जावास्क्रिप्ट तर्क से भरे घटकों में HTML और CSS के मिश्रण के साथ नहीं डाल सकता। मैं समझता हूं कि यह समस्या क्या हल करती है, लेकिन यह दृष्टिकोण जिन समस्याओं को लाता है, वे इसे इसके लायक नहीं बनाते हैं।

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

कोड दोहराव

एसपीए के साथ काम करते समय, आप शायद कोड दोहराव का सामना करेंगे।

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

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

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

आप शर्त लगा सकते हैं कि आपको अपने एसपीए में एक अमीर मॉडल की आवश्यकता नहीं है और आप यूआई के घटकों में तर्क को वितरित करते हुए सीधे JSON / जावास्क्रिप्ट वस्तुओं के साथ काम करेंगे। अब आपके यूआई कोड के साथ समान कोड डुप्लिकेट है, इसके साथ शुभकामनाएं।

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

सर्वर और क्लाइंट पर पैटर्न के तर्क को पुन: प्रस्तुत करने की आवश्यकता, मेरे अनुभव में, प्रोग्रामर्स के बढ़ते दुर्भाग्य का स्रोत है। एक बार ऐसा करने के लिए सामान्य है। जब आप 20 वीं बार ऐसा करेंगे, तो आप अपना सिर पकड़ लेंगे। 50 वीं बार ऐसा करने पर, आप सोचेंगे कि इन सभी एसपीए के टुकड़ों की आवश्यकता है या नहीं।

भंगुरता

मेरे अनुभव में, अच्छा एसपीए विकसित करना सर्वर पीढ़ी के साथ वेब एप्लिकेशन लिखने की तुलना में अधिक जटिल कार्य है।

पहला, आप चाहे कितने भी सावधान क्यों न हों, आप कितने भी टेस्ट लिख लें। आप जितना अधिक कोड लिखेंगे, आपके पास उतने अधिक बग होंगे। और एसपीए प्रतिनिधित्व करता है (क्षमा करें, अगर मैं कड़ी मेहनत करता हूं) लेखन और समर्थन के लिए कोड का एक बड़ा ढेर।

दूसरे, जैसा कि ऊपर उल्लेख किया गया है, एक समृद्ध जीयूआई विकसित करना जटिल है और एक दूसरे के साथ बातचीत करने वाले कई तत्वों से मिलकर जटिल प्रणालियों में अनुवाद करता है। आपके द्वारा बनाए गए सिस्टम जितने अधिक जटिल होंगे, आपके पास उतने अधिक बग होंगे। और एमवीसी का उपयोग करते हुए पारंपरिक वेब अनुप्रयोगों की तुलना में, स्पा जटिलता सिर्फ पागल है।

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

संगठनात्मक चुनौतियां

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

आपके विचार से आपकी कंपनी के लिए यह शायद अधिक महत्वपूर्ण चुनौती है। एसपीए का दृष्टिकोण सामान्यवादियों की टीमों के बजाय अत्यधिक विशिष्ट टीमों को प्रोत्साहित करता है:

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

संभावना यह है कि आप अपने आप को उन लोगों के साथ पाएंगे जो एसपीए के साथ काम नहीं कर सकते हैं, और जो सर्वर साइड पर काम नहीं कर सकते हैं, केवल इसलिए कि वे नहीं जानते कि कैसे।

यह विशेषज्ञता फेसबुक या Google और उनकी टीमों के लिए आदर्श हो सकती है, जिसमें इंजीनियरिंग टुकड़ियों की कई परतें होती हैं। लेकिन क्या यह आपकी 6 लोगों की टीम के लिए अच्छा होगा?

आधुनिक रेल

आधुनिक रेल में जाने वाली 3 चीजें हैं जो आधुनिक वेब एप्लिकेशन विकसित करने के बारे में आपका मन बदल सकती हैं:

• उनमें से एक टर्बोलिंक है और यह एक मस्तिष्क विस्फोट है
• दूसरा एक पुराना मित्र है जिसे आज अनदेखा किया गया है: SJR प्रतिक्रियाओं और प्रतिपादन के लिए सरल AJAX अनुरोध
• और पिछले एक को हाल ही में जोड़ा गया था: स्टिमुलस

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

Turbolinks

टर्बोलिंक्स के पीछे का विचार सरल है: AJAX अनुरोधों के साथ पृष्ठ री-लोड को पूरी तरह से बदलकर अपने आवेदन को गति दें जो `` तत्व को प्रतिस्थापित करता है। यह काम करने वाला आंतरिक जादू टोना छिपा हुआ है। एक डेवलपर के रूप में, आप पारंपरिक सर्वर-साइड प्रोग्रामिंग पर ध्यान केंद्रित कर सकते हैं।

टर्बोलिंक्स पजाक्स से प्रेरित है और कई संशोधनों से गुजरा है।

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

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

मुझे उन कुछ समस्याओं पर प्रकाश डालते हैं जो इसे ठीक करती हैं:

• डेटा विनिमय। तुम्हारे पास नहीं है। JSON को अनुक्रमित करने, API बनाने या डेटा अनुरोधों के बारे में सोचने की ज़रूरत नहीं है जो प्रदर्शन के मामले में ग्राहकों की ज़रूरतों को पूरा करते हैं।
• प्रारंभिक भार। एसपीए के विपरीत, यह दृष्टिकोण तेजी से लोडिंग समय (डिजाइन द्वारा) को उत्तेजित करता है। स्क्रीन रेंडर करने के लिए, आपको वह डेटा मिल सकता है, जिसकी आपको सीधे डेटाबेस से जरूरत होती है। HTML — .
• : JavaScript-. , SPA.

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

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

• कोड दोहराव। आपके एप्लिकेशन का केवल एक ही दृश्य है जो सर्वर पर रहता है। आपका डोमेन मॉडल, उसके नियम, एप्लिकेशन स्क्रीन इत्यादि। ग्राहक में अवधारणाओं की नकल करने की आवश्यकता नहीं है।
• . SPA, JavaScript , . , , , .

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

बेशक, टर्बोलिंक एक परेशानी मुक्त चांदी की गोली नहीं है। सबसे बड़ी समस्या यह है कि यह मौजूदा जावास्क्रिप्ट कोड को तोड़ सकता है:

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

AJAX प्रतिपादन और SJR जवाब

याद रखें जब 15 साल पहले अजाक्स के माध्यम से HTML रेंडर किया गया था? क्या लगता है? यह अभी भी आपके शस्त्रागार में एक महान उपकरण है:

• HTML DOM, ( 100 ).
• HTML , .

शीर्ष दाईं ओर दिए गए बटन पर क्लिक करके आप देख सकते हैं कि बेसकैंप में यह तरीका कैसा महसूस होता है:



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

एक समान उपकरण जिसे रेल ने वर्षों से शामिल किया है वह सर्वर-साइड जावास्क्रिप्ट (एसजेआर) प्रतिक्रियाएं हैं। वे आपको अजाक्स अनुरोधों का जवाब देने की अनुमति देते हैं (आमतौर पर प्रस्तुतियाँ) जावास्क्रिप्ट के साथ जो क्लाइंट द्वारा निष्पादित किया जाता है। यह HTML स्निपेट्स के AJAX प्रतिपादन के समान लाभ प्रदान करता है: यह बहुत तेजी से चलता है, आप सर्वर साइड पर कोड का पुन: उपयोग कर सकते हैं, और आप प्रतिक्रिया बनाने के लिए डेटाबेस तक सीधे पहुंच सकते हैं।

आप देख सकते हैं कि यह कैसे होता है यदि आप बेसकैंप में जाते हैं और एक नया टूडू बनाने की कोशिश करते हैं। "टूडू जोड़ें" पर क्लिक करने के बाद, सर्वर टूडू को बचाएगा और एक डीएनएस टुकड़े के साथ प्रतिक्रिया करेगा जो डोम में एक नया टूडू जोड़ता है।

मुझे लगता है कि कई डेवलपर्स आज अवमानना ​​के साथ AJAX प्रतिपादन और SJR प्रतिक्रियाओं को देखते हैं। मुझे वह भी याद है। वे एक उपकरण हैं और, जैसे, उनका दुरुपयोग किया जा सकता है। लेकिन जब सही तरीके से उपयोग किया जाता है, तो यह एक भयानक समाधान है। आपको बहुत ही कम कीमत में शानदार UX और अन्तरक्रियाशीलता प्रदान करते हैं। दुर्भाग्य से, टर्बोलिंक्स की तरह, उनका मूल्यांकन करना मुश्किल है यदि आपने अभी तक एसपीए नहीं लड़ा है।

प्रोत्साहन

स्टिमुलस कुछ महीनों पहले प्रकाशित एक जावास्क्रिप्ट ढांचा है। यह प्रतिपादन या जावास्क्रिप्ट-आधारित राज्य प्रबंधन के बारे में परवाह नहीं करता है। इसके बजाय, यह जावास्क्रिप्ट को व्यवस्थित करने का सिर्फ एक अच्छा, आधुनिक तरीका है, जिसका उपयोग आप HTML जोड़ने के लिए करते हैं:

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

यदि आप रेल पथ को स्वीकार करते हैं, तो आपका जावास्क्रिप्ट सर्वर-साइड HTML कोड को संशोधित करने और इंटरैक्शन में सुधार करने पर ध्यान केंद्रित करेगा (जावास्क्रिप्ट के एक बिट के साथ)। स्टिमुलस को ऐसे कोड को व्यवस्थित करने के लिए डिज़ाइन किया गया है। यह एक एसपीए प्रणाली नहीं है और यह एक होने का दिखावा नहीं करता है।

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

समझौता का खेल

टर्बोलिंक्स आमतौर पर "बिना किसी असुविधा के एसपीए के सभी लाभ प्राप्त करें" के रूप में बेचा जाता है। मुझे नहीं लगता कि यह पूरी तरह सच है:

• आधुनिक रेल का उपयोग करके बनाए गए एप्लिकेशन तेजी से दिखते हैं, लेकिन एसपीए अभी भी उन इंटरैक्शन का तेजी से जवाब देगा जो सर्वर-स्वतंत्र हैं।
• ऐसे परिदृश्य हैं जिनमें एसपीए अधिक समझ में आता है। यदि आपको उच्च स्तर की अन्तरक्रियाशीलता की पेशकश करने की आवश्यकता है, तो आपको बड़ी संख्या में राज्यों का प्रबंधन करने, क्लाइंट पक्ष पर जटिल तर्क निष्पादित करने आदि की आवश्यकता है, एसपीए फ्रेमवर्क आपके जीवन को आसान बना देगा।

अब विकास समझौता का खेल है। और इस खेल में:

• आधुनिक रेल आपको ऐसे एप्लिकेशन बनाने की अनुमति देती है जो बहुत तेज़ हैं और बहुत अच्छे लगते हैं।
• विभिन्न प्रकार के अनुप्रयोगों के लिए, रेल आपको कम कोड और कम जटिलता वाले समान कार्यों को लागू करने की अनुमति देता है।

मेरा मानना ​​है कि रेल के साथ आप 90% पा सकते हैं जो एसपीए 10% प्रयास के साथ प्रदान करता है। प्रदर्शन के मामले में, रेल्स ने एसपीए को मार दिया। UX के रूप में, मुझे लगता है कि कई डेवलपर्स मेरे जैसी ही गलती करते हैं, यह मानते हुए कि SPA UX नायाब है। ऐसा नहीं है। वास्तव में, जैसा कि ऊपर चर्चा की गई है, आप बेहतर जानते हैं कि आप अपना एसपीए बनाते समय क्या कर रहे हैं, या यूएक्स वास्तव में बदतर होगा।

निष्कर्ष

मैं देखता हूं कि कंपनियां बड़े पैमाने पर एसपीए फ्रेमवर्क स्वीकार करती हैं और फैंसी एसपीए शैली की चीजों को करने के लिए अनगिनत लेख देखती हैं। मुझे लगता है कि कई "काम के लिए गलत उपकरण का उपयोग करता है", क्योंकि मैं दृढ़ता से मानता हूं कि एसपीए के उपयोग को सही ठहराने वाले अनुप्रयोगों के प्रकार सीमित हैं।

और मैं कहता हूं कि वे इसे सही ठहराते हैं क्योंकि एसपीए जटिल हैं। किसी भी मामले में, मुझे आशा है कि मैंने आपको इस बारे में आश्वस्त किया है। मैं यह नहीं कह रहा हूं कि महान एसपीए एप्लिकेशन बनाना असंभव है, या यह कि आधुनिक रेल एप्लिकेशन परिभाषा से महान हैं, बस एक दृष्टिकोण सुपर जटिल है और दूसरा बहुत सरल है।

इस लेख को तैयार करते समय, मैं इस ट्वीट पर आया:



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

कई सालों के बाद, मुझे एहसास हुआ कि जटिलता अक्सर एक विकल्प होती है। लेकिन प्रोग्रामिंग दुनिया में, सादगी का चयन करना आश्चर्यजनक रूप से कठिन है। हम जटिलता को इतना महत्व देते हैं कि सादगी को स्वीकार करना अक्सर हमें अलग तरह से सोचना पड़ता है, जो कि मुश्किल है।

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

और यदि आप एक रेल डेवलपर हैं, जिसने कई साल पहले रेल छोड़ दी है, तो मैं आपको इसे वापस करने की सलाह देता हूं। मुझे लगता है कि आप प्रसन्न होंगे।