आर्किटेक्चर

अपने ऐप्लिकेशन को ऐसी टेक्नोलॉजी का ज़्यादा से ज़्यादा इस्तेमाल करने के लिए डिज़ाइन करना जो PWA को भरोसेमंद, इंस्टॉल करने लायक, और बेहतर बनाती है. इसके लिए, अपने ऐप्लिकेशन और उसकी सीमाओं को समझना शुरू करें. साथ ही, दोनों के लिए सही आर्किटेक्चर चुनें.

एसपीए बनाम एमपीए

फ़िलहाल, वेब डेवलपमेंट में दो मुख्य आर्किटेक्चर पैटर्न मौजूद हैं: सिंगल-पेज ऐप्लिकेशन या एसपीए और कई पेज वाले ऐप्लिकेशन या MPA.

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

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

PWA बनाने के लिए, दोनों आर्किटेक्चर का इस्तेमाल किया जा सकता है.

इन दोनों के अपने फ़ायदे और नुकसान हैं. उपयोगकर्ताओं को तेज़ और भरोसेमंद अनुभव देने के लिए, अपने हिसाब से सही विकल्प चुनना ज़रूरी है.

एक पेज वाले ऐप्लिकेशन

फ़ायदे
  • ज़्यादातर मामलों में, पेज पर छोटे-छोटे अपडेट.
  • स्टार्ट-अप पर लोड की गई क्लाइंट-साइड डिपेंडेंसी.
  • कैश मेमोरी के इस्तेमाल की वजह से, इसके बाद लोड तेज़ी से होता है.
नुकसान
  • लोड करने की शुरुआती लागत ज़्यादा है.
  • परफ़ॉर्मेंस, डिवाइस हार्डवेयर और इंटरनेट कनेक्शन पर निर्भर करती है.
  • ऐप्लिकेशन जटिल होना ज़रूरी है.

एक पेज वाले ऐप्लिकेशन, वास्तुकला के लिए सही होते हैं, अगर:

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

एसपीए, आर्किटेक्चर का अच्छा विकल्प नहीं हो सकता, अगर:

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

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

कई पेज वाले ऐप्लिकेशन

फ़ायदे
  • ज़्यादातर पेज पूरे पेज पर अपडेट होते हैं.
  • शुरुआत में रेंडर होने की स्पीड बहुत ज़रूरी होती है.
  • क्लाइंट-साइड स्क्रिप्टिंग की मदद से, बेहतर नतीजे पाए जा सकते हैं.
नुकसान
  • सेकंडरी व्यू के लिए दूसरे सर्वर कॉल की ज़रूरत होती है.
  • अलग-अलग व्यू के बीच का संदर्भ, अलग-अलग हो सकता है.
  • इसके लिए सर्वर या प्री-रेंडरिंग की ज़रूरत होती है.

कई पेजों वाले ऐप्लिकेशन, इन मामलों में बेहतरीन काम करते हैं:

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

एमपीए का इस्तेमाल करना अच्छा नहीं होगा, अगर:

  • JavaScript या सीएसएस को फिर से डाउनलोड करना, फिर से पार्स करना, और फिर से चलाना बहुत महंगा होता है. PWA में, सर्विस वर्कर की मदद से इस समस्या को कम किया जाता है.
  • क्लाइंट-साइड कॉन्टेक्स्ट, जैसे कि उपयोगकर्ता की जगह की जानकारी का इस्तेमाल एक व्यू के बीच आसानी से नहीं किया जा सकता. इसलिए, कॉन्टेक्स्ट को फिर से पाना महंगा हो सकता है. इसे या तो कैप्चर करके वापस पाना होगा या व्यू के बीच फिर से अनुरोध करना होगा.

अलग-अलग व्यू को ऐक्सेस करने से पहले, सर्वर की मदद से डाइनैमिक तौर पर रेंडर होना या पहले से रेंडर किया जाना ज़रूरी होता है. इससे, होस्टिंग को सीमित किया जा सकता है या डेटा को समझना मुश्किल हो सकता है.

किसे चुनना है?

इन फ़ायदों और नुकसान के साथ भी, दोनों आर्किटेक्चर का इस्तेमाल PWA को बनाने के लिए किया जा सकता है. ऐप्लिकेशन के अलग-अलग हिस्सों के लिए भी इन प्रॉडक्ट को मिक्स किया जा सकता है. जैसे, ऐप्लिकेशन की ज़रूरत के हिसाब से, स्टोर पेज का MPA आर्किटेक्चर का इस्तेमाल किया जाता है और चेकआउट फ़्लो, एसपीए आर्किटेक्चर के हिसाब से होता है.

चाहे कोई भी विकल्प हो, अगला चरण यह समझना है कि सबसे अच्छा अनुभव देने के लिए सर्विस वर्कर का सबसे सही तरीके से इस्तेमाल कैसे किया जाए.

सर्विस वर्कर की ताकत

सर्विस वर्कर के पास बेसिक रूटिंग और कैश मेमोरी और नेटवर्क रिस्पॉन्स की डिलीवरी के अलावा भी काफ़ी काम होता है. हम जटिल एल्गोरिदम बना सकते हैं जो उपयोगकर्ता के अनुभव और परफ़ॉर्मेंस को बेहतर बना सकते हैं.

सर्विस वर्कर में शामिल हैं (एसडब्ल्यूआई)

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

यह इमेज, सैंपल के तौर पर सेट वेब पेज है. इसमें पांच अलग-अलग सेक्शन होते हैं, जो पेज को इन पांच हिस्सों में बांटते हैं:

  • पूरा लेआउट.
  • ग्लोबल हेडर (सबसे ऊपर गहरे रंग वाला बार).
  • कॉन्टेंट एरिया (बीच में बाईं ओर की लाइनें और इमेज).
  • साइडबार (मध्यम दाईं ओर मध्यम-गहरे रंग का बड़ा बार).
  • फ़ुटर (गहरे रंग वाला सबसे नीचे वाला बार).

पूरा लेआउट

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

ग्लोबल हेडर और फ़ुटर में, टॉप मेन्यू और साइट में मौजूद फ़ुटर जैसी चीज़ें शामिल होती हैं. इनसे एक चुनौती मिलती है: अगर पूरे पेज को कैश मेमोरी में सेव किया जाता है, तो पेज लोड होने के बीच बदलाव भी हो सकता है. हालांकि, यह इस बात पर निर्भर करता है कि उस पेज को कैश मेमोरी में कब सेव किया गया था.

उन्हें अलग-अलग करके और कॉन्टेंट के बिना कैश मेमोरी में सेव करके, आप यह पक्का कर सकते हैं कि उपयोगकर्ताओं को हमेशा एक जैसा वर्शन मिले, चाहे वे कैश मेमोरी में कब भी सेव किए गए हों. इन्हें कभी-कभी अपडेट किया जाता है. इसलिए, प्रीकैशिंग के लिए भी इनका इस्तेमाल किया जा सकता है. हालांकि, इनमें साइट की सीएसएस और JavaScript पर निर्भरता होती है.

सीएसएस और JavaScript

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

कॉन्टेंट एरिया

आगे है कॉन्टेंट के बारे में. अपडेट की फ़्रीक्वेंसी के आधार पर, दोबारा पुष्टि करने के दौरान, पहले वाले नेटवर्क या पुराने नेटवर्क से जुड़ी रणनीति सही है. इमेज को कैश मेमोरी में सेव करने की पहली रणनीति का इस्तेमाल करके कैश मेमोरी में सेव किया जाना चाहिए, जैसा कि पहले बताया गया है.

आखिर में, यह मानते हुए कि साइडबार की सामग्री में टैग और संबंधित आइटम जैसी दूसरी सामग्री है, नेटवर्क से लेना काफ़ी अहम नहीं है. इसके लिए फिर से सत्यापित करने वाली कार्यनीति काम करती है.

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

खुद आज़माकर देखें

आप अगले कोडलैब के साथ शामिल किए गए सर्विस वर्कर को आज़मा सकते हैं:

जवाब स्ट्रीम किए जा रहे हैं

पिछले पेज को एसपीए की दुनिया में ऐप शेल मॉडल का इस्तेमाल करके बनाया जा सकता था, जहां ऐप शेल को कैश मेमोरी में सेव किया जाता है, फिर दिखाया जाता है. साथ ही, कॉन्टेंट को क्लाइंट साइड पर लोड किया जाता है. Streams API की शुरुआत और सभी के लिए उपलब्ध होने की वजह से, ऐप्लिकेशन शेल और सामग्री, दोनों को सर्विस वर्कर में जोड़ा जा सकता है और ब्राउज़र पर स्ट्रीम किया जा सकता है. इससे आपको MPA की गति के साथ ऐप्लिकेशन शेल को कैश मेमोरी में सेव करने की सुविधा मिलती है.

ऐसा इसलिए किया जाता है, क्योंकि:

  • स्ट्रीम को एसिंक्रोनस तरीके से बनाया जा सकता है, जिससे किसी स्ट्रीम के अलग-अलग हिस्से दूसरे स्रोतों से आ सकते हैं.
  • स्ट्रीम का अनुरोध करने वाला व्यक्ति, डेटा के पहले हिस्से के उपलब्ध होते ही जवाब देने की प्रोसेस शुरू कर सकता है. इससे वह पूरा आइटम प्रोसेस होने का इंतज़ार नहीं करता.
  • स्ट्रीमिंग के लिए ऑप्टिमाइज़ किए गए पार्सर, स्ट्रीम के पूरा होने से पहले ही उसके कॉन्टेंट को दिखा सकते हैं. इसमें ब्राउज़र भी शामिल है. इससे, प्रतिक्रिया देने की प्रोसेस तेज़ हो जाती है.

स्ट्रीम की इन तीन प्रॉपर्टी की वजह से, आम तौर पर स्ट्रीम करने के लिए बने आर्किटेक्चर की परफ़ॉर्मेंस, उस स्ट्रीम की तुलना में ज़्यादा तेज़ होती है.

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

डोमेन, ऑरिजिन, और PWA का स्कोप

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

एक ही ऑरिजिन से जुड़ी नीति

अगर प्रोटोकॉल, पोर्ट, और होस्ट एक जैसे हैं, तो दो यूआरएल का ऑरिजिन सटीक होता है.

उदाहरण के लिए: https://squoosh.app और https://squoosh.app/v2 का ऑरिजिन एक ही है, लेकिन http://squoosh.app, https://squoosh.com, https://app.squoosh.app, और https://squoosh.app:8080 अलग-अलग ऑरिजिन से हैं. ज़्यादा जानकारी और उदाहरणों के लिए, एक ही ऑरिजिन वाली नीति के एमडीएन का रेफ़रंस देखें.

सबडोमेन में बदलाव करना ही होस्ट के बदलने का एक तरीका नहीं है. हर होस्ट में एक टॉप लेवल डोमेन (टीएलडी), एक सेकंडरी लेवल डोमेन (एसएलडी), और शून्य या उससे ज़्यादा लेबल (कभी-कभी सबडोमेन कहा जाता है) होते हैं. इन लेबल के बीच में बिंदु होते हैं और उन्हें यूआरएल में दाएं से बाएं पढ़ा जाता है. किसी भी आइटम में बदलाव करने से, दूसरा होस्ट बन जाता है.

विंडो मैनेजमेंट मॉड्यूल में, हमने पहले ही देख लिया है कि जब कोई उपयोगकर्ता इंस्टॉल किए गए PWA से किसी अलग ऑरिजिन पर जाता है, तो इन-ऐप्लिकेशन ब्राउज़र कैसा दिखता है.

वह इन-ऐप्लिकेशन ब्राउज़र तब भी दिखेगा, जब वेबसाइटों के टीएलडी और एसएलडी एक ही हों, लेकिन लेबल अलग-अलग हों. ऐसा इसलिए, क्योंकि फिर उन्हें अलग-अलग ऑरिजिन माना जाता है.

वेब-ब्राउज़िंग के संदर्भ में ऑरिजिन के अहम पहलुओं में से एक यह है कि स्टोरेज और अनुमतियां कैसे काम करती हैं. एक ऑरिजिन अपने सभी कॉन्टेंट और PWA के साथ कई सुविधाएं शेयर करता है, जैसे:

  • स्टोरेज कोटा और डेटा (IndexedDB, कुकी, वेब स्टोरेज, कैश मेमोरी).
  • सर्विस वर्कर के रजिस्ट्रेशन.
  • दी या अस्वीकार की गई अनुमतियां, जैसे कि वेब पुश, जियोलोकेशन, सेंसर.
  • वेब पुश रजिस्ट्रेशन.

एक ऑरिजिन से दूसरे ऑरिजिन पर जाने पर, पुराना ऐक्सेस वापस ले लिया जाता है. इसलिए, अनुमतियां फिर से देनी पड़ती हैं और आपका PWA, स्टोरेज में सेव किए गए सारे डेटा को ऐक्सेस नहीं कर सकता.

रिसॉर्स