एक ही डोमेन नेम का फ़ायदा उठाकर, एक से ज़्यादा PWA बनाने का तरीका. इससे उपयोगकर्ता को यह पता चलता है कि वे एक ही संगठन या सेवा से जुड़े हैं.
एक से ज़्यादा ऑरिजिन वाली साइटों में प्रोग्रेसिव वेब ऐप्लिकेशन बनाने के बारे में जानकारी देने वाली ब्लॉग पोस्ट में, डेमियन ने उन चुनौतियों के बारे में बताया है जिनका सामना, एक से ज़्यादा ऑरिजिन पर बनाई गई साइटों को एक ऐसा प्रोग्रेसिव वेब ऐप्लिकेशन बनाने के दौरान करना पड़ता है जिसमें वे सभी शामिल हों.
इस तरह के साइट आर्किटेक्चर का एक उदाहरण, ई-कॉमर्स साइट है, जहां:
- होम पेज
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एक ऑरिजिन है.
जैसा कि नाम से पता चलता है, एक ही ऑरिजिन वाली नीति, ऑरिजिन पर पाबंदियां लगाती है. इसलिए, हम इस लेख में इस शब्द का ज़्यादातर इस्तेमाल करेंगे. इसके बावजूद, हम अलग-अलग "ऑरिजिन" बनाने के लिए, इस्तेमाल की जा रही तकनीक के बारे में बताने के लिए, समय-समय पर "डोमेन" या "सबडोमेन" का इस्तेमाल करेंगे.
एक-दूसरे से मिलते-जुलते कई PWA बनाने का फ़ायदा
कुछ मामलों में, हो सकता है कि आपको अलग-अलग ऐप्लिकेशन बनाने हों, लेकिन फिर भी उन्हें एक ही संगठन या "ब्रैंड" के तौर पर पहचानना हो. उसी डोमेन नेम का फिर से इस्तेमाल करना, उस संबंध को स्थापित करने का एक अच्छा तरीका है. उदाहरण के लिए:
- कोई ई-कॉमर्स साइट, सेलर को अपनी इन्वेंट्री मैनेज करने की सुविधा देना चाहती है. साथ ही, यह भी पक्का करना चाहती है कि सेलर को पता हो कि यह सुविधा, मुख्य वेबसाइट से जुड़ी है जहां लोग प्रॉडक्ट खरीदते हैं.
- खेल से जुड़ी खबरों की एक साइट, किसी बड़े खेल के इवेंट के लिए एक खास ऐप्लिकेशन बनाना चाहती है, ताकि उपयोगकर्ताओं को सूचनाओं के ज़रिए अपने पसंदीदा मुकाबलों के आंकड़े मिल सकें. साथ ही, इसे प्रोग्रेसिव वेब ऐप्लिकेशन के तौर पर इंस्टॉल किया जा सके. साथ ही, यह भी पक्का किया जा सके कि उपयोगकर्ता इसे खबरों की कंपनी के बनाए गए ऐप्लिकेशन के तौर पर पहचान सकें.
- कोई कंपनी अलग-अलग चैट, मेल, और कैलेंडर ऐप्लिकेशन बनाना चाहती है. साथ ही, वह चाहती है कि ये ऐप्लिकेशन, कंपनी के नाम से जुड़े अलग-अलग ऐप्लिकेशन के तौर पर काम करें.
अलग-अलग ऑरिजिन का इस्तेमाल करना
ऐसे मामलों में हमारा सुझाव है कि हर अलग कॉन्सेप्ट वाले ऐप्लिकेशन को अपने ओरिजिन पर लाइव करें.
अगर आपको सभी साइटों में एक ही डोमेन नेम का इस्तेमाल करना है, तो सबडोमेन का इस्तेमाल करें. उदाहरण के लिए, एक ऐसी कंपनी जो कई इंटरनेट ऐप्लिकेशन या सेवाएं उपलब्ध कराती है, वह 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 की ओर से अपलोड की गई फ़ोटो