एक से ज़्यादा मूल साइटों में प्रोग्रेसिव वेब ऐप्लिकेशन

एक से ज़्यादा ऑरिजिन वाली साइटों में प्रोग्रेसिव वेब ऐप्लिकेशन बनाने में आने वाली चुनौतियां और समाधान.

Demián Renzulli

बैकग्राउंड

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

एक से ज़्यादा ऑरिजिन का इस्तेमाल करके अच्छा और गलत इस्तेमाल

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

अच्छा

आइए, पहले उपयोगी वजहों पर नज़र डालते हैं:

• लोकलाइज़ेशन / भाषा: देश के कोड वाले टॉप लेवल डोमेन का इस्तेमाल करके, अलग-अलग देशों में दिखाने के लिए साइटों को अलग-अलग करना (जैसे, https://www.google.com.ar). इसके अलावा, अलग-अलग जगहों को टारगेट की गई साइटों को अलग-अलग दिखाने के लिए सबडोमेन का इस्तेमाल करना (उदाहरण के लिए: https://newyork.craigslist.org) या किसी खास भाषा (जैसे कि https://en.wikipedia.org) के लिए कॉन्टेंट उपलब्ध कराना.

• स्वतंत्र वेब ऐप्लिकेशन: अलग-अलग सबडोमेन का इस्तेमाल करके ऐसे अनुभव देना जिनका मकसद साइट के मुख्य ऑरिजिन से काफ़ी अलग हो. उदाहरण के लिए, किसी समाचार साइट में, क्रॉसवर्ड वेबऐप्लिकेशन को https://crosswords.example.com से जान-बूझकर दिखाया जा सकता है. साथ ही, इसे स्वतंत्र PWA के तौर पर इंस्टॉल और इस्तेमाल किया जा सकता है. इसके लिए, मुख्य वेबसाइट के साथ कोई संसाधन या सुविधा शेयर नहीं करनी पड़ती.

खराब

अगर आप इनमें से कोई भी काम नहीं कर रहे हैं, तो यह संभव है कि प्रोग्रेसिव वेब ऐप्लिकेशन बनाते समय मल्टी-ऑरिजिन आर्किटेक्चर का इस्तेमाल करने से नुकसान होगा.

इसके बावजूद, कई साइटों को बिना किसी वजह या 'लेगसी' वजहों से इस तरह से स्ट्रक्चर किया जाता रहता है. इसका एक उदाहरण यह है कि सबडोमेन का इस्तेमाल करके, किसी साइट के उन हिस्सों को मनचाहे तरीके से अलग-अलग किया जा सकता है जिन्हें एक ही जगह पर देखने की सुविधा का हिस्सा होना चाहिए.

उदाहरण के लिए, नीचे दिए गए पैटर्न का सुझाव नहीं दिया जाता:

• साइट सेक्शन: सबडोमेन पर किसी साइट के अलग-अलग सेक्शन को अलग करना. समाचार साइटों में, होम पेज https://www.example.com पर दिखता है. हालांकि, खेल-कूद वाला सेक्शन https://sports.example.com, राजनीति, https://politics.example.com वगैरह में दिखता है. ई-कॉमर्स साइट के मामले में, प्रॉडक्ट कैटगरी के लिए https://category.example.com, प्रॉडक्ट पेजों के लिए https://product.example.com वगैरह का इस्तेमाल करना.

• उपयोगकर्ता फ़्लो: साइट के अलग-अलग छोटे हिस्सों, जैसे कि सबडोमेन में लॉगिन या खरीदारी फ़्लो के लिए पेज जैसे अलग-अलग तरीके का इस्तेमाल न करने का सुझाव दिया जाता है. उदाहरण के लिए, https://login.example.com और https://checkout.example.com का इस्तेमाल करना.

उन मामलों में जहां एक ऑरिजिन पर माइग्रेट करना मुमकिन नहीं है, उनके लिए यहां दी गई चुनौतियों की सूची दी गई है. साथ ही, (जहां मुमकिन हो), ऐसे तरीके दिए गए हैं जिन पर प्रोग्रेसिव वेब ऐप्लिकेशन बनाते समय विचार किया जा सकता है.

अलग-अलग ऑरिजिन के लिए उपलब्ध पीडब्ल्यूए की समस्याएं और उन्हें हल करने के तरीके

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

सर्विस वर्कर

सर्विस वर्कर स्क्रिप्ट यूआरएल का ऑरिजिन, register() को कॉल करने वाले पेज के ऑरिजिन से मेल खाना चाहिए. इसका मतलब है कि उदाहरण के लिए, https://www.example.com पर मौजूद कोई पेज, https://section.example.com पर सर्विस वर्कर यूआरएल के साथ register() को कॉल नहीं कर सकता.

दूसरा विचार यह है कि सर्विस वर्कर सिर्फ़ ऑरिजिन और पाथ से जुड़े पेजों को ही कंट्रोल कर सकता है. इसका मतलब है कि अगर सर्विस वर्कर https://www.example.com पर होस्ट किया गया है, तो वह सिर्फ़ उस ऑरिजिन के यूआरएल को कंट्रोल कर सकता है (स्कोप पैरामीटर में बताए गए पाथ के मुताबिक). हालांकि, वह दूसरे सबडोमेन, जैसे कि https://section.example.com में मौजूद किसी भी पेज को कंट्रोल नहीं कर पाएगा.

इस मामले में, समाधान सिर्फ़ एक से ज़्यादा सर्विस वर्कर (हर ऑरिजिन के लिए एक) का इस्तेमाल करना होता है.

कैश मेमोरी में सेव करना

कैश ऑब्जेक्ट, indexDB, और localStorage भी एक ही ऑरिजिन तक सीमित हैं. इसका मतलब है कि https://www.example.com से जुड़ी कैश मेमोरी को ऐक्सेस नहीं किया जा सकता, उदाहरण के लिए: https://www.section.example.com.

यहां कुछ ऐसी चीज़ों के बारे में बताया गया है, जिनकी मदद से इस तरह की स्थितियों में कैश मेमोरी को सही तरीके से मैनेज किया जा सकता है:

• ब्राउज़र की कैश मेमोरी का फ़ायदा लें: हमारा सुझाव है कि आप ब्राउज़र को कैश मेमोरी में सेव करने के पारंपरिक सबसे सही तरीके इस्तेमाल करें. यह तकनीक, कैश मेमोरी में सेव किए गए रिसॉर्स को ऑरिजिन में फिर से इस्तेमाल करने का अतिरिक्त फ़ायदा देती है. सर्विस वर्कर की कैश मेमोरी से इन संसाधनों को फिर से इस्तेमाल नहीं किया जा सकता. सर्विस वर्कर के साथ एचटीटीपी कैश का इस्तेमाल करने के सबसे सही तरीके जानने के लिए, यह पोस्ट पढ़ें.

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

अनुमतियां

अनुमतियां भी ऑरिजिन के दायरे में आती हैं. इसका मतलब है कि अगर किसी उपयोगकर्ता ने ऑरिजिन https://section.example.com को किसी तरह की अनुमति दी है, तो उसे https://www.example.com जैसे दूसरे ऑरिजिन पर नहीं ले जाया जाएगा.

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

इंस्टॉल करना

PWA इंस्टॉल करने के लिए, हर ऑरिजिन का अपना मेनिफ़ेस्ट होना चाहिए. साथ ही, ऐसा start_url होना चाहिए जो अलग-अलग हो. इसका मतलब है कि किसी खास ऑरिजिन (https://section.example.com) पर इंस्टॉल करने का अनुरोध पाने वाले उपयोगकर्ता को, start_url वाले PWA को किसी दूसरे ऑरिजिन (https://www.example.com) पर इंस्टॉल नहीं करना होगा. दूसरे शब्दों में, किसी सबडोमेन में इंस्टॉल करने का अनुरोध पाने वाले उपयोगकर्ता, सिर्फ़ सबपेज के लिए PWA इंस्टॉल कर पाएंगे, न कि ऐप्लिकेशन के मुख्य यूआरएल के लिए.

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

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

1. beforeinstallprompt इवेंट सुनें.
2. event.preventDefault() को कॉल करके, प्रॉम्प्ट को दिखने से रोकें.

इस तरह, यह पक्का किया जा सकता है कि प्रॉम्प्ट, साइट के अनचाहे हिस्सों में न दिखे. हालांकि, इस प्रॉम्प्ट को साइट के मुख्य ऑरिजिन में (जैसे, होम पेज) दिखाया जा सकता है.

स्टैंडअलोन मोड

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

ज़्यादातर मामलों में, इसका कोई समाधान नहीं होता. हालांकि, सबडोमेन में होस्ट किए गए अनुभव के छोटे हिस्सों (उदाहरण के लिए: लॉगिन वर्कफ़्लो) के लिए समाधान लागू किया जा सकता है:

1. नया यूआरएल, https://login.example.com, फ़ुल स्क्रीन iframe में खुल सकता है.
2. iframe (उदाहरण के लिए, लॉगिन प्रोसेस) में टास्क पूरा हो जाने के बाद, postMessage() का इस्तेमाल करके iframe से मिलने वाली किसी भी जानकारी को वापस पैरंट पेज पर भेजें.
3. आखिरी चरण में, मुख्य पेज पर मैसेज मिलने के बाद, लिसनर का रजिस्ट्रेशन रद्द किया जा सकता है. साथ ही, iframe को डीओएम से हटाया जा सकता है.

नतीजा

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

इस तरीके से पहले से बनी मौजूदा साइटों के लिए, एक से ज़्यादा ऑरिजिन वाले PWA को सही तरीके से काम करना मुश्किल लग सकता है. हालांकि, हमने कुछ संभावित विकल्प भी ढूंढे हैं. इनमें से हर एक के साथ कुछ चीज़ें बदल सकती हैं, इसलिए अपनी सूझ-बूझ का इस्तेमाल करके तय करें कि आपको अपनी वेबसाइट के लिए कौनसा तरीका अपनाना चाहिए.

लंबी अवधि के लिए रणनीति या साइट को फिर से डिज़ाइन करते समय, किसी एक ऑरिजिन पर माइग्रेट करें. ऐसा तब तक करें, जब तक मल्टी-ऑरिजिन आर्किटेक्चर को बनाए रखने की कोई अहम वजह न हो.

तकनीकी समीक्षाओं और सुझावों के लिए हम सभी का शुक्रिया अदा करते हैं: पेनी मक्लेचलान, पॉल कोवेल, डॉमिनिक एनजी, अल्बर्टो मेडिना, पीट लेपेज, जो मेडली, चेनी साई, मार्टिन शिएर्ल, और आंद्रे बंडारा.