आइसोमॉर्फिक जावास्क्रिप्ट - वेब अनुप्रयोगों का भविष्य

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

यह आज एक सामान्य दृष्टिकोण है जब पुस्तकालयों जैसे कि backbone.js, ember.js और angular.js डेवलपर्स को शक्तिशाली जावास्क्रिप्ट एप्लिकेशन बनाने में मदद करते हैं। हालांकि, हमने महसूस किया कि ऐसे अनुप्रयोगों की कई महत्वपूर्ण सीमाएँ हैं। इसे स्पष्ट करने के लिए, आइए वेब अनुप्रयोगों के इतिहास का एक छोटा दौरा लें।

_{ध्यान आकर्षित करने के लिए लेख से छवि}

जावास्क्रिप्ट बढ़ रही है

वेब की सुबह में, ब्राउज़रों के साथ बातचीत इस प्रकार थी: एक वेब ब्राउज़र ने एचटीएमएल उत्पन्न करने और उसे वापस भेजने के लिए इंटरनेट पर कहीं स्थित सर्वर को मजबूर करने के लिए हर पृष्ठ (उदाहरण के लिए, www.geocities.com ) का अनुरोध किया था। यह एक अच्छा दृष्टिकोण था, क्योंकि उस समय ब्राउज़र अभी तक बहुत शक्तिशाली नहीं थे, और HTML पृष्ठ ज्यादातर स्थिर और स्वायत्त थे। वेब पेजों को अधिक गतिशील बनाने के लिए डिज़ाइन किए गए जावास्क्रिप्ट ने स्लाइड शो या डेट पिकर की तुलना में अधिक जटिल कुछ भी करने की अनुमति नहीं दी।

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

एकल पृष्ठ अनुप्रयोग

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

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



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

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

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

स्वर्ग में त्रास

व्यवहार में, हालांकि, इस दृष्टिकोण में कई घातक दोष हैं जो इसे कई मामलों में उपयोग करने से रोकते हैं।

खोज इंजन अनुकूलन

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

उत्पादकता

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

समर्थन

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

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

हाइब्रिड दृष्टिकोण

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

इसे प्राप्त करने के लिए, हम, Airbnb पर, "आइसोमॉर्फिक जावास्क्रिप्ट अनुप्रयोगों", जावास्क्रिप्ट अनुप्रयोगों के साथ प्रयोग कर रहे हैं जो क्लाइंट और सर्वर दोनों पर चल सकते हैं।

एक आइसोमॉर्फिक एप्लिकेशन कुछ इस तरह दिखता है। "क्लाइंट-सर्वर MVC":



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

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

जंगली में आइसोमोर्फिक जावास्क्रिप्ट

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

मोजिटो पहले ज्ञात आइसोमोर्फिक ओपन सोर्स फ्रेमवर्क था। यह एक उन्नत, फुल-स्टैक फ्रेमवर्क है जो नोड.जेएस पर आधारित है, लेकिन यह यूईआई पर निर्भर करता है, और याहू के quirks ने जावास्क्रिप्ट समुदाय में इसकी विशेष लोकप्रियता में योगदान नहीं दिया है क्योंकि यह अप्रैल 2012 में खुला था।

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

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

हमने इस साल अपनी आइसोमॉर्फिक लाइब्रेरी भी बनाई। इसे रेंड्र कहा जाता है। यह आपको backbone.js + handlebars.js सिंगल-पेज एप्लिकेशन बनाने की अनुमति देता है जो सर्वर पर पूरी तरह से पेज भी बना सकते हैं। Rendr Airbnb के मोबाइल संस्करण को डाउनलोड करने की गति को सुधारने में हमारे अनुभव का परिणाम है, जो कि मोबाइल उपयोगकर्ताओं के लिए विशेष रूप से महत्वपूर्ण है, जो डेटा ट्रांसफर में उच्च अक्षांशों की विशेषता है। रेंड्र एक लाइब्रेरी से अधिक है जो कई समस्याओं को हल करता है (यदि आप इसकी तुलना Mojito या Meteor से करते हैं), लेकिन इसे संशोधित करना और विस्तार करना आसान है।

अमूर्तन, अमूर्तता, अमूर्तता

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

मार्ग

हमें उन मार्गों का एक सेट चाहिए, जो उपयुक्त हैंडलर के लिए विशिष्ट URI पैटर्न को मैप करते हैं। इन हैंडलर तक पहुंच होनी चाहिए: HTTP हेडर, कुकीज, यूआरआई से जानकारी और रीडायरेक्ट करने की क्षमता बिना विंडोज़ के सीधे एक्सेस (ब्राउजर में) और रीक और रेस (नोड.जेएस में)।

डेटा को लोड करना और सहेजना

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

पेज जनरेशन

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

विधानसभा और पैकेजिंग

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

हम छोटे मॉड्यूल से इकट्ठा होते हैं

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

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

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

चारों ओर देखिए

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

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

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