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