मल्टी-ऑरिजिन साइटों में प्रोग्रेसिव वेब ऐप्लिकेशन बनाने में आने वाली चुनौतियां और उन्हें हल करने के तरीके.
पब्लिश होने की तारीख: 19 अगस्त, 2019
पहले, मल्टी-ऑरिजिन आर्किटेक्चर का इस्तेमाल करने के कुछ फ़ायदे थे. प्रोग्रेसिव वेब ऐप्लिकेशन के लिए, इस तरीके से कई चुनौतियां सामने आती हैं. खास तौर पर, एक ही ऑरिजिन वाली नीति, सर्विस वर्कर और कैश मेमोरी, अनुमतियों जैसी चीज़ों को शेयर करने पर पाबंदियां लगाती है. साथ ही, यह नीति कई ऑरिजिन पर अलग से अनुभव पाने के लिए भी पाबंदियां लगाती है.
एक से ज़्यादा ऑरिजिन इस्तेमाल करने के फ़ायदे और नुकसान जानें. साथ ही, एक से ज़्यादा ऑरिजिन वाली साइटों में प्रोग्रेसिव वेब ऐप्लिकेशन बनाने से जुड़ी चुनौतियों और उनके समाधान के बारे में जानें.
एक से ज़्यादा ऑरिजिन इस्तेमाल करने के सही और गलत तरीके
साइटों के लिए मल्टी-ऑरिजिन आर्किटेक्चर का इस्तेमाल करने की कुछ मान्य वजहें हैं. इनमें से ज़्यादातर वजहें, वेब ऐप्लिकेशन का एक अलग सेट उपलब्ध कराने या ऐसे अनुभव बनाने से जुड़ी हैं जो एक-दूसरे से पूरी तरह अलग हों. इसके अलावा, कुछ मामलों में इसका इस्तेमाल नहीं किया जाना चाहिए.
अच्छा भी
सबसे पहले, काम के होने की वजहें देखें:
स्थानीय भाषा / भाषा: देश के कोड के हिसाब से टॉप लेवल डोमेन का इस्तेमाल करके, अलग-अलग देशों में दिखाई जाने वाली साइटों को अलग-अलग करना (जैसे,
https://www.google.com.ar) या सबडोमेन का इस्तेमाल करके, अलग-अलग जगहों को टारगेट करने वाली साइटों को बांटना (जैसे:https://newyork.craigslist.org) या किसी खास भाषा में कॉन्टेंट उपलब्ध कराने के लिए किया जाता है (जैसे,https://en.wikipedia.org).अलग-अलग वेब ऐप्लिकेशन: अलग-अलग सबडोमेन का इस्तेमाल करके, ऐसे अनुभव देना जिनका मकसद मुख्य ऑरिजिन वाली साइट से काफ़ी अलग हो. उदाहरण के लिए, किसी समाचार साइट में, क्रॉसवर्ड वेब ऐप्लिकेशन को जान-बूझकर
https://crosswords.example.comसे उपलब्ध कराया जा सकता है. साथ ही, इसे एक स्वतंत्र पीडब्ल्यूए के तौर पर इंस्टॉल और इस्तेमाल किया जा सकता है. इसके लिए, मुख्य वेबसाइट के साथ कोई भी संसाधन या फ़ंक्शन शेयर करने की ज़रूरत नहीं होती.
बुरा भी
अगर इनमें से कोई भी काम नहीं किया जा रहा है, तो हो सकता है कि प्रोग्रेसिव वेब ऐप्लिकेशन बनाते समय, मल्टी-ऑरिजिन आर्किटेक्चर का इस्तेमाल करने से आपको नुकसान हो.
इसके बावजूद, कई साइटें बिना किसी खास वजह या 'लेगसी' वजहों से इस तरह से स्ट्रक्चर्ड होती हैं. इसका एक उदाहरण है, सबडोमेन का इस्तेमाल करके किसी साइट के उन हिस्सों को अलग करना जो एक ही अनुभव का हिस्सा होने चाहिए.
उदाहरण के लिए, इन पैटर्न का इस्तेमाल करने से बचें:
साइट के सेक्शन: सबडोमेन पर, साइट के अलग-अलग सेक्शन को अलग-अलग करना. समाचार साइटों में, होम पेज को
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 अनुभव देना मुश्किल होता है. इसकी मुख्य वजह एक ही ऑरिजिन वाली नीति है, जो कई पाबंदियां लगाती है. आइए, एक-एक करके इनके बारे में जानते हैं.
सर्विस वर्कर
सर्विस वर्कर स्क्रिप्ट के यूआरएल का ऑरिजिन, 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 के साथ पीडब्ल्यूए इंस्टॉल नहीं कर पाएगा.
दूसरे शब्दों में, सबडोमेन में इंस्टॉलेशन का प्रॉम्प्ट पाने वाले उपयोगकर्ता, सिर्फ़ सबपेज के लिए पीडब्ल्यूए इंस्टॉल कर पाएंगे, न कि ऐप्लिकेशन के मुख्य यूआरएल के लिए.
एक समस्या यह भी है कि साइट पर नेविगेट करते समय, एक ही उपयोगकर्ता को इंस्टॉल करने के कई प्रॉम्प्ट मिल सकते हैं. ऐसा तब होता है, जब हर सबडोमेन इंस्टॉल करने की ज़रूरी शर्तें पूरी करता हो और उपयोगकर्ता को पीडब्ल्यूए इंस्टॉल करने के लिए प्रॉम्प्ट करता हो.
इस समस्या को कम करने के लिए, यह पक्का किया जा सकता है कि प्रॉम्प्ट सिर्फ़ मुख्य ऑरिजिन पर दिखे. जब कोई उपयोगकर्ता किसी ऐसे सबडोमेन पर जाता है जो इंस्टॉल करने की ज़रूरी शर्तें पूरी करता है, तो:
beforeinstallpromptइवेंट के लिए सुनें.- प्रॉम्प्ट को दिखने से रोकें,
event.preventDefault()को कॉल करें.
इससे यह पक्का किया जा सकता है कि प्रॉम्प्ट, साइट के उन हिस्सों में न दिखे जहां उसे नहीं दिखाना है. हालांकि, इसे मुख्य ऑरिजिन (जैसे, होम पेज) पर दिखाया जा सकता है.
स्टैंडअलोन मोड
अलग से मौजूद विंडो में नेविगेट करते समय, ब्राउज़र अलग तरह से काम करेगा. ऐसा तब होगा, जब उपयोगकर्ता PWA के मेनिफ़ेस्ट से सेट किए गए स्कोप से बाहर जाएगा. यह हर ब्राउज़र के वर्शन और वेंडर पर निर्भर करता है. उदाहरण के लिए, Chrome के नए वर्शन में, जब कोई उपयोगकर्ता स्टैंडअलोन मोड में स्कोप से बाहर जाता है, तो Chrome कस्टम टैब खुलता है.
ज़्यादातर मामलों में, इसका कोई समाधान नहीं होता. हालांकि, सबडोमेन में होस्ट किए गए अनुभव के छोटे हिस्सों के लिए, कोई तरीका अपनाया जा सकता है. उदाहरण के लिए: लॉगिन वर्कफ़्लो:
- नया यूआरएल,
https://login.example.com, फ़ुल स्क्रीन iframe में खुल सकता है. - iframe में टास्क पूरा होने के बाद (उदाहरण के लिए, लॉगिन की प्रोसेस), postMessage() का इस्तेमाल किया जा सकता है. इससे iframe से मिली किसी भी जानकारी को पैरंट पेज पर वापस भेजा जा सकता है.
- आखिरी चरण के तौर पर, मुख्य पेज को मैसेज मिलने के बाद, लिसनर का रजिस्ट्रेशन रद्द किया जा सकता है. साथ ही, iframe को DOM से हटाया जा सकता है.
नतीजा
सेम-ऑरिजिन नीति, कई ऑरिजिन पर बनी उन साइटों पर कई पाबंदियां लगाती है जो एक जैसा पीडब्ल्यूए अनुभव देना चाहती हैं. इसलिए, उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, हमारा सुझाव है कि साइटों को अलग-अलग ऑरिजिन में न बांटें.
पहले से मौजूद ऐसी साइटों के लिए, मल्टी-ऑरिजिन पीडब्ल्यूए को सही तरीके से काम करने लायक बनाना मुश्किल हो सकता है. हालांकि, हमने कुछ संभावित समाधान खोजे हैं. हर तरीके के अपने फ़ायदे और नुकसान होते हैं. इसलिए, अपनी वेबसाइट के लिए कौनसा तरीका अपनाना है, यह तय करने के लिए अपनी सूझ-बूझ का इस्तेमाल करें.
लंबी अवधि की रणनीति या साइट को फिर से डिज़ाइन करने का आकलन करते समय, एक ही ऑरिजिन पर माइग्रेट करने के बारे में सोचें. हालांकि, अगर कई ऑरिजिन वाले आर्किटेक्चर को बनाए रखने की कोई ज़रूरी वजह है, तो ऐसा न करें.
तकनीकी समीक्षाओं और सुझावों के लिए, इन लोगों का बहुत-बहुत धन्यवाद: पेनी मैक्लाक्लन, पॉल कोवेल, डॉमिनिक एनजी, अल्बर्टो मदीना, पीट लेपेज, जो मेडली, चेनी त्साई, मार्टिन शियरले, और आंद्रे बंडारा.