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

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

Demián Renzulli

पब्लिश होने की तारीख: 19 अगस्त, 2019

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

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

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

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

अच्छा भी

सबसे पहले, इन वजहों को देखें:

• स्थानीय भाषा / भाषा: अलग-अलग देशों में दिखाई जाने वाली साइटों को अलग करने के लिए, देश के कोड वाला टॉप-लेवल डोमेन का इस्तेमाल करना (जैसे, 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 का इस्तेमाल करना.

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

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

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

सर्विस वर्कर

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

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

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

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

Cache ऑब्जेक्ट, 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 इंस्टॉल नहीं कर पाएंगे.

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

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

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

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

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

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

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

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

नतीजा

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

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

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

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