एक ही डोमेन नेम का इस्तेमाल करके, कई पीडब्ल्यूए बनाने का तरीका, ताकि उपयोगकर्ताओं को यह पता चल सके कि वे एक ही संगठन या सेवा से जुड़े हैं.
मल्टी-ऑरिजिन साइटों में प्रोग्रेसिव वेब ऐप्लिकेशन के बारे में ब्लॉग पोस्ट में, डेमियन ने उन चुनौतियों के बारे में बताया है जिनका सामना, एक से ज़्यादा ऑरिजिन पर बनाई गई साइटों को एक ऐसा प्रोग्रेसिव वेब ऐप्लिकेशन बनाने के दौरान करना पड़ता है जिसमें वे सभी शामिल हों.
इस तरह के साइट आर्किटेक्चर का एक उदाहरण, ई-कॉमर्स साइट है, जहां:
- होम पेज
https://www.example.comपर है. - कैटगरी पेजों को
https://category.example.comपर होस्ट किया जाता है. https://product.example.comपर मौजूद प्रॉडक्ट की जानकारी वाले पेज.
जैसा कि लेख में बताया गया है, एक ही ऑरिजिन वाली नीति कई पाबंदियां लगाती है. इन पाबंदियों की वजह से, सर्विस वर्कर, कैश मेमोरी, और अनुमतियों को सभी ऑरिजिन के साथ शेयर नहीं किया जा सकता. इस वजह से, हमारा सुझाव है कि आप इस तरह के कॉन्फ़िगरेशन और ऐसे कॉन्फ़िगरेशन इस्तेमाल न करें जिनकी इस तरह की साइटें पहले से बनी हुई हैं. ऐसा इसलिए किया जाता है, ताकि जब भी मुमकिन हो, एक ऑरिजिन साइट आर्किटेक्चर पर माइग्रेट किया जाए.
इस पोस्ट में, हम इसके उलट मामले पर नज़र डालेंगे: अलग-अलग ऑरिजिन के एक PWA के बजाय, हम उन कंपनियों के मामले का विश्लेषण करेंगे जो एक ही डोमेन नेम का फ़ायदा उठाकर, एक से ज़्यादा PWA उपलब्ध कराना चाहती हैं. साथ ही, उपयोगकर्ता को यह बताना चाहती हैं कि वे PWA एक ही संगठन या सेवा से जुड़े हैं.
आपने देखा होगा कि हम अलग-अलग, लेकिन एक-दूसरे से जुड़े शब्द इस्तेमाल कर रहे हैं, जैसे कि डोमेन और ऑरिजिन. आगे बढ़ने से पहले, इन कॉन्सेप्ट की समीक्षा करते हैं.
तकनीकी शर्तें
- डोमेन: डोमेन नेम सिस्टम (डीएनएस) में बताए गए लेबल का कोई भी क्रम.
उदाहरण के लिए:
comऔरexample.comडोमेन हैं. - होस्टनेम: ऐसी डीएनएस एंट्री जो कम से कम एक आईपी पते से जुड़ी होती है. उदाहरण
के लिए:
www.example.comएक होस्टनेम होगा, अगरexample.comका कोई आईपी पता था, तो यह एक होस्टनेम हो सकता है. साथ ही,comकभी भी आईपी पते के तौर पर काम नहीं करेगा और इसलिए यह कभी होस्टनेम नहीं होगा. - ऑरिजिन: स्कीम, होस्टनेम, और (ज़रूरी नहीं) पोर्ट का कॉम्बिनेशन. उदाहरण के लिए,
https://www.example.com:443एक ऑरिजिन है.
जैसा कि नाम से पता चलता है, एक ही ऑरिजिन वाली नीति, ऑरिजिन पर पाबंदियां लगाती है. इसलिए, हम इस लेख में इस शब्द का ज़्यादातर इस्तेमाल करेंगे. इसके बावजूद, हम समय-समय पर "डोमेन" या "सबडोमेन" का इस्तेमाल करेंगे. इससे, अलग-अलग "ऑरिजिन" बनाने के लिए, इस्तेमाल की जा रही तकनीक के बारे में बताया जा सकेगा.
एक से ज़्यादा पीडब्ल्यूए का केस
कुछ मामलों में, हो सकता है कि आपको अलग-अलग ऐप्लिकेशन बनाने हों, लेकिन फिर भी उन्हें एक ही संगठन या "ब्रैंड" से जुड़े ऐप्लिकेशन के तौर पर दिखाना हो. उसी डोमेन नेम का फिर से इस्तेमाल करना, उस संबंध को स्थापित करने का एक अच्छा तरीका है. उदाहरण के लिए:
- कोई ई-कॉमर्स साइट, सेलर को अपनी इन्वेंट्री मैनेज करने की सुविधा देना चाहती है. साथ ही, यह भी पक्का करना चाहती है कि सेलर को पता हो कि यह सुविधा, मुख्य वेबसाइट से जुड़ी है जहां लोग प्रॉडक्ट खरीदते हैं.
- खेल से जुड़ी खबरों की एक साइट, किसी बड़े खेल के इवेंट के लिए एक खास ऐप्लिकेशन बनाना चाहती है, ताकि उपयोगकर्ताओं को सूचनाओं के ज़रिए अपने पसंदीदा मुकाबलों के आंकड़े मिल सकें. साथ ही, इसे प्रोग्रेसिव वेब ऐप्लिकेशन के तौर पर इंस्टॉल किया जा सके. साथ ही, यह पक्का किया जा सके कि उपयोगकर्ता इसे खबरों की कंपनी के बनाए गए ऐप्लिकेशन के तौर पर पहचान सकें.
- एक कंपनी अलग-अलग चैट, मेल, और कैलेंडर ऐप्लिकेशन बनाना चाहती है और चाहती है कि वह कंपनी के नाम से जुड़े अलग-अलग ऐप्लिकेशन की तरह काम करे.
अलग-अलग ऑरिजिन का इस्तेमाल करना
ऐसे मामलों में हमारा सुझाव है कि हर अलग कॉन्सेप्ट वाले ऐप्लिकेशन को अपने ऑरिजिन पर लाइव करें.
अगर आपको सभी साइटों में एक ही डोमेन नेम का इस्तेमाल करना है, तो सबडोमेन का इस्तेमाल करें. उदाहरण के लिए, एक ऐसी कंपनी जो कई इंटरनेट ऐप्लिकेशन या सेवाएं उपलब्ध कराती है, वह https://mail.example.com पर मेल ऐप्लिकेशन और https://calendar.example.com पर कैलेंडर ऐप्लिकेशन होस्ट कर सकती है. साथ ही, https://www.example.com पर अपने कारोबार की मुख्य सेवा उपलब्ध करा सकती है. एक और उदाहरण, कोई ऐसी स्पोर्ट्स साइट है जो किसी अहम स्पोर्ट्स इवेंट के लिए, पूरी तरह से अलग ऐप्लिकेशन बनाना चाहती है. जैसे, https://footballcup.example.com में होने वाली फ़ुटबॉल चैंपियनशिप. इस ऐप्लिकेशन को उपयोगकर्ता, https://www.example.com पर होस्ट की गई मुख्य स्पोर्ट्स साइट से अलग से इंस्टॉल और इस्तेमाल कर सकते हैं. यह तरीका उन प्लैटफ़ॉर्म के लिए भी मददगार हो सकता है जो ग्राहकों को कंपनी के ब्रैंड के तहत, अपने ऐप्लिकेशन बनाने की सुविधा देते हैं.
उदाहरण के लिए, ऐसा ऐप्लिकेशन जिसकी मदद से व्यापारी/कंपनी/कारोबारी, https://merchant1.example.com, https://merchant2.example.com वगैरह पर अपने PWA बना सकते हैं.
अलग-अलग ऑरिजिन का इस्तेमाल करने से, ऐप्लिकेशन के बीच अलगाव बना रहता है. इसका मतलब है कि उनमें से हर ऐप्लिकेशन, ब्राउज़र की अलग-अलग सुविधाओं को अलग से मैनेज कर सकता है. इनमें ये सुविधाएं शामिल हैं:
- इंस्टॉल करने की सुविधा: हर ऐप्लिकेशन का अपना मेनिफ़ेस्ट होता है और वह इंस्टॉल करने का अपना अनुभव देता है.
- डिवाइस का स्टोरेज: हर ऐप्लिकेशन की अपनी कैश मेमोरी, लोकल स्टोरेज, और डिवाइस में सेव सभी तरह का स्टोरेज होता है. इन्हें अन्य ऐप्लिकेशन के साथ शेयर नहीं किया जाता.
- सर्विस वर्कर्स: रजिस्टर किए गए स्कोप के लिए, हर ऐप्लिकेशन का अपना सर्विस वर्कर्स होता है.
- अनुमतियां: अनुमतियों का दायरा ऑरिजिन के हिसाब से भी होता है. इससे, उपयोगकर्ताओं को यह पता चल पाएगा कि वे किस सेवा के लिए अनुमतियां दे रहे हैं. साथ ही, सूचनाओं जैसी सुविधाओं को हर ऐप्लिकेशन के लिए सही तरीके से एट्रिब्यूट किया जाएगा.
एक से ज़्यादा अलग-अलग PWA के इस्तेमाल के मामले में, इस तरह के अलग-अलग पहलुओं को इस्तेमाल करना सबसे ज़रूरी होता है. इसलिए, हमारा सुझाव है कि आप यही तरीका अपनाएं.
अगर सबडोमेन पर मौजूद ऐप्लिकेशन, एक-दूसरे के साथ लोकल डेटा शेयर करना चाहते हैं, तो वे अब भी कुकी के ज़रिए ऐसा कर पाएंगे. इसके अलावा, ज़्यादा बेहतर सुविधाओं के लिए, वे सर्वर के ज़रिए स्टोरेज को सिंक कर सकते हैं.
एक ही ऑरिजिन का इस्तेमाल करना
दूसरा तरीका, एक ही ऑरिजिन पर अलग-अलग PWA बनाना है. इसमें, इन स्थितियों की जानकारी शामिल है:
नॉन-ओवरलैपिंग पाथ
एक ही ऑरिजिन पर होस्ट किए गए कई PWA या कॉन्सेप्ट वाले "वेब ऐप्लिकेशन", जिनके पाथ एक-दूसरे से ओवरलैप न होते हों. उदाहरण के लिए:
https://example.com/app1/https://example.com/app2/
ओवरलैपिंग/नेस्ट किए गए पाथ
एक ही ऑरिजिन पर कई PWA, जिनमें से किसी एक का स्कोप दूसरे के अंदर नेस्ट किया गया हो:
https://example.com/("बाहरी ऐप्लिकेशन")https://example.com/app/("इनर ऐप्लिकेशन")
सर्विस वर्कर एपीआई और मेनिफ़ेस्ट फ़ॉर्मैट की मदद से, पाथ-लेवल स्कोपिंग का इस्तेमाल करके, इनमें से कोई भी काम किया जा सकता है. हालांकि, दोनों ही मामलों में एक ही ऑरिजिन का इस्तेमाल करने से कई समस्याएं और सीमाएं आती हैं. इन समस्याओं की वजह यह है कि ब्राउज़र इन ऐप्लिकेशन को अलग-अलग "ऐप्लिकेशन" के तौर पर पूरी तरह से नहीं मानता. इसलिए, इस तरीके का इस्तेमाल करने का सुझाव नहीं दिया जाता.
अगले सेक्शन में, हम इन चुनौतियों का ज़्यादा बारीकी से विश्लेषण करते हैं. साथ ही, हम यह भी बताते हैं कि अलग-अलग ऑरिजिन का इस्तेमाल करने का विकल्प न होने पर क्या किया जा सकता है.
एक ही ऑरिजिन वाले कई PWA के लिए चुनौतियां
एक ही सोर्स वाले दोनों तरीकों में, ये कुछ सामान्य समस्याएं होती हैं:
- स्टोरेज: कुकी, लोकल स्टोरेज, और डिवाइस के लोकल स्टोरेज के सभी फ़ॉर्म, ऐप्लिकेशन के बीच शेयर किए जाते हैं. इस वजह से, अगर उपयोगकर्ता किसी ऐप्लिकेशन का लोकल डेटा मिटाता है, तो ऑरिजिन से उसका सारा डेटा मिट जाएगा. किसी एक ऐप्लिकेशन के लिए ऐसा करने का कोई तरीका नहीं है. ध्यान दें कि Chrome और कुछ अन्य ब्राउज़र, किसी ऐप्लिकेशन को अनइंस्टॉल करते समय उपयोगकर्ताओं को लोकल डेटा मिटाने के लिए लगातार सूचना देंगे. इससे ऑरिजिन पर मौजूद अन्य ऐप्लिकेशन के डेटा पर भी असर पड़ेगा. एक और समस्या यह है कि ऐप्लिकेशन को अपना स्टोरेज कोटा भी शेयर करना होगा. इसका मतलब है कि अगर इनमें से कोई एक ऐप्लिकेशन बहुत ज़्यादा जगह ले लेता है, तो दूसरे ऐप्लिकेशन पर इसका बुरा असर पड़ेगा.
- अनुमतियां: ब्राउज़र की अनुमतियां, ऑरिजिन से जुड़ी होती हैं. इसका मतलब है कि अगर कोई उपयोगकर्ता किसी एक ऐप्लिकेशन को अनुमति देता है, तो वह उस ऑरिजिन के सभी ऐप्लिकेशन पर एक साथ लागू हो जाएगी. यह ठीक लग सकता है (कई बार अनुमति मांगने की ज़रूरत नहीं है), लेकिन याद रखें: अगर कोई उपयोगकर्ता किसी एक ऐप्लिकेशन को अनुमति नहीं मांगता है, तो वह दूसरे लोगों को उस अनुमति का अनुरोध करने या उस सुविधा का इस्तेमाल करने से रोक देगा. ध्यान दें कि भले ही, ब्राउज़र की अनुमतियां हर ऑरिजिन के लिए सिर्फ़ एक बार दी जानी चाहिए, लेकिन सिस्टम-लेवल की अनुमतियां हर ऐप्लिकेशन के लिए एक बार दी जानी चाहिए. भले ही, एक से ज़्यादा ऐप्लिकेशन एक ही ऑरिजिन पर ले जाते हों.
- उपयोगकर्ता सेटिंग: सेटिंग, हर ऑरिजिन के हिसाब से भी सेट की जाती हैं. उदाहरण के लिए, अगर दो ऐप्लिकेशन के फ़ॉन्ट साइज़ अलग-अलग हैं और उपयोगकर्ता को फ़ॉन्ट साइज़ में अंतर को कम करने के लिए, सिर्फ़ एक ऐप्लिकेशन में ज़ूम को अडजस्ट करना है, तो वह ऐसा नहीं कर पाएगा. इसके लिए, उसे दूसरे ऐप्लिकेशन में भी सेटिंग लागू करनी होगी.
इन चुनौतियों की वजह से, इस तरीके को बढ़ावा देना मुश्किल हो जाता है. हालांकि, अगर आपके पास अलग-अलग ऑरिजिन का इस्तेमाल करना सेक्शन में बताए गए तरीके से, अलग-अलग ऑरिजिन (जैसे, सबडोमेन) का इस्तेमाल करने का विकल्प नहीं है, तो हमारा सुझाव है कि आप एक ही ऑरिजिन के दो विकल्पों में से, ओवरलैप होने वाले/नेस्ट किए गए पाथ के बजाय, ओवरलैप न होने वाले पाथ का इस्तेमाल करें.
जैसा कि बताया गया है, इस सेक्शन में बताई गई चुनौतियां, एक ही ऑरिजिन वाले दोनों तरीकों के लिए समान हैं. अगले सेक्शन में, हम इस बारे में ज़्यादा जानकारी देंगे कि ओवरलैप करने वाले/नेस्ट किए गए पाथ का इस्तेमाल करने का सुझाव क्यों नहीं दिया जाता.
ओवरलैप/नेस्ट किए गए पाथ से जुड़ी अन्य चुनौतियां
ओवरलैप/नेस्ट किए गए पाथ के तरीके (जहां https://example.com/ बाहरी ऐप्लिकेशन है और https://example.com/app/ अंदरूनी ऐप्लिकेशन है) से जुड़ी एक और समस्या यह है कि अंदरूनी ऐप्लिकेशन के सभी यूआरएल को असल में बाहरी ऐप्लिकेशन और अंदरूनी ऐप्लिकेशन, दोनों का हिस्सा माना जाएगा.
इसमें नीचे दी गई समस्याएं होती हैं:
- इंस्टॉल करने का प्रमोशन: अगर उपयोगकर्ता किसी इनर ऐप्लिकेशन (जैसे, किसी वेब ब्राउज़र) पर जाता है, तो उसके डिवाइस पर आउटर ऐप्लिकेशन पहले से इंस्टॉल होने पर ब्राउज़र, इंस्टॉल से जुड़े प्रमोशन वाले बैनर नहीं दिखाएगा. साथ ही, beforeInstallPrompt इवेंट को ट्रिगर नहीं किया जाएगा. इसकी वजह यह है कि ब्राउज़र यह जांच करेगा कि मौजूदा पेज, पहले से इंस्टॉल किए गए ऐप्लिकेशन से जुड़ा है या नहीं. साथ ही, यह भी पता लगाएगा कि यह ऐप्लिकेशन, बाहरी ऐप्लिकेशन से पहले इंस्टॉल किया गया है या नहीं. इस समस्या को हल करने के लिए, अंदरूनी ऐप्लिकेशन को मैन्युअल तरीके से इंस्टॉल करें. इसके लिए, ब्राउज़र के मेन्यू में "शॉर्टकट बनाएं" विकल्प का इस्तेमाल करें. इसके अलावा, बाहरी ऐप्लिकेशन से पहले, अंदरूनी ऐप्लिकेशन को इंस्टॉल करें.
- सूचना और Badging API: अगर बाहरी ऐप्लिकेशन इंस्टॉल है, लेकिन अंदरूनी ऐप्लिकेशन नहीं है, तो अंदरूनी ऐप्लिकेशन से मिलने वाली सूचनाएं और बैज, बाहरी ऐप्लिकेशन को गलत तरीके से एट्रिब्यूट कर दिए जाएंगे. बाहरी ऐप्लिकेशन, इंस्टॉल किए गए ऐप्लिकेशन के सबसे नज़दीक का स्कोप होता है. यह सुविधा तब ठीक से काम करती है, जब उपयोगकर्ता के डिवाइस पर दोनों ऐप्लिकेशन इंस्टॉल होते हैं.
- लिंक कैप्चर करना: बाहरी ऐप्लिकेशन, अंदरूनी ऐप्लिकेशन से जुड़े यूआरएल कैप्चर कर सकता है. ऐसा तब होता है, जब बाहरी ऐप्लिकेशन इंस्टॉल हो, लेकिन अंदरूनी ऐप्लिकेशन न हो. इसी तरह, बाहरी ऐप्लिकेशन में मौजूद ऐसे लिंक जो अंदरूनी ऐप्लिकेशन से लिंक होते हैं, वे अंदरूनी ऐप्लिकेशन में लिंक कैप्चर नहीं करेंगे. ऐसा इसलिए, क्योंकि उन्हें बाहरी ऐप्लिकेशन के दायरे में माना जाता है. इसके अलावा, ChromeOS और Android पर, अगर इन ऐप्लिकेशन को Play Store में (भरोसेमंद वेब ऐक्टिविटी के तौर पर) जोड़ा जाता है, तो आउटर ऐप्लिकेशन सभी लिंक कैप्चर कर लेगा. भले ही, अंदरूनी ऐप्लिकेशन इंस्टॉल हो, फिर भी ओएस उपयोगकर्ता को बाहरी ऐप्लिकेशन में लिंक खोलने का विकल्प देगा.
नतीजा
इस लेख में, हमने उन अलग-अलग तरीकों के बारे में बताया है जिनकी मदद से डेवलपर, एक ही डोमेन में एक-दूसरे से जुड़े कई प्रोग्रेसिव वेब ऐप्लिकेशन बना सकते हैं.
खास जानकारी के तौर पर, हमारा सुझाव है कि अलग-अलग PWA होस्ट करने के लिए, किसी दूसरे ऑरिजिन (उदाहरण के लिए, सबडोमेन का इस्तेमाल करके) का इस्तेमाल करें. इन्हें एक ही ऑरिजिन में होस्ट करने से कई समस्याएं आती हैं. इसकी मुख्य वजह यह है कि ब्राउज़र इन्हें अलग-अलग ऐप्लिकेशन के तौर पर पूरी तरह से नहीं मानता.
- अलग-अलग ऑरिजिन: सुझाया गया
- एक ही ऑरिजिन और ओवरलैप न होने वाले पाथ: इसका सुझाव नहीं दिया जाता
- एक ही ऑरिजिन, ओवरलैप होने वाले/नेस्ट किए गए पाथ: इसका सुझाव बिलकुल नहीं दिया जाता
अगर अलग-अलग ऑरिजिन का इस्तेमाल नहीं किया जा सकता, तो हमारा सुझाव है कि आप ओवरलैप न करने वाले पाथ (जैसे, https://example.com/app1/ और https://example.com/app2/) का इस्तेमाल करें. ऐसा करने से, ओवरलैप या नेस्ट किए गए पाथ (जैसे, https://example.com/ (बाहरी ऐप्लिकेशन के लिए) और https://example.com/app/ (अंदरूनी ऐप्लिकेशन के लिए) का इस्तेमाल करने से बचा जा सकता है.
अन्य संसाधन
तकनीकी समीक्षाओं और सुझावों के लिए धन्यवाद: जो मेडली, डोमिनिक एनजी, एलन कटर, डैनियल मर्फ़ी, पेनी मैक्लचलन, थॉमस स्टाइनर, और डार्विन हुआंग
Unsplash पर Tim Mossholder की ओर से अपलोड की गई फ़ोटो