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

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

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 का इस्तेमाल करना.

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

अलग-अलग ऑरिजिन के लिए, PWA से जुड़ी समस्याएं और उनका हल

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

सर्विस वर्कर

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

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

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

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

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

इस तरह की स्थितियों में कैश मेमोरी को सही तरीके से मैनेज करने के लिए, ये काम किए जा सकते हैं:

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

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

अनुमतियां

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

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

इंस्टॉल करना

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

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

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

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

इस तरह, यह पक्का किया जा सकता है कि प्रॉम्प्ट, साइट के ग़ैर-ज़रूरी हिस्सों में न दिखाया जाए. हालांकि, इसे मुख्य ऑरिजिन (उदाहरण के लिए, होम पेज) में दिखाना जारी रखा जा सकता है.

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

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

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

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

नतीजा

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

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

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

तकनीकी समीक्षाओं और सुझावों के लिए धन्यवाद: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle, और Andre Bandarra.