एक ही डोमेन पर, कई प्रोग्रेसिव वेब ऐप्लिकेशन बनाना

एक ही डोमेन नेम का इस्तेमाल करके, कई PWA बनाने का तरीका, ताकि उपयोगकर्ता को यह बताया जा सके कि वे एक ही संगठन या सेवा से जुड़े हैं.

चेज़ फ़िलिप्स

डेमियन रेंज़ुली

मैट गुका

कई ऑरिजिन वाली साइटों के ब्लॉग पोस्ट में, Demian ने एक प्रोग्रेसिव वेब ऐप्लिकेशन बनाने की कोशिश करते समय उन चुनौतियों के बारे में बताया जो कई ऑरिजिन पर बनी थीं.

इस तरह की साइट के आर्किटेक्चर का एक उदाहरण कोई ई-कॉमर्स साइट है, जहां:

• होम पेज 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://www.example.com पर उपलब्ध कराने के साथ-साथ, https://mail.example.com पर मेल ऐप्लिकेशन और https://calendar.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/, इनर ऐप्लिकेशन है) यह है कि इनर ऐप्लिकेशन में मौजूद सभी यूआरएल, असल में आउटर ऐप्लिकेशन और इनर ऐप्लिकेशन, दोनों का हिस्सा माने जाएंगे.

व्यावहारिक रूप से, यह इन समस्याओं के बारे में बताता है:

• इंस्टॉल करने का प्रमोशन: अगर उपयोगकर्ता, उपयोगकर्ता के डिवाइस में पहले से ही आउटर ऐप्लिकेशन इंस्टॉल है, तो वह इनर ऐप्लिकेशन (उदाहरण के लिए, किसी वेब ब्राउज़र में) पर जाता है, तो ब्राउज़र, इंस्टॉल प्रमोशन वाला बैनर नहीं दिखाएगा. साथ ही, इससे पहले इंस्टॉल करने से जुड़े प्रॉम्प्ट इवेंट को ट्रिगर नहीं किया जाएगा. इसकी वजह यह है कि ब्राउज़र जांच करके यह देखेगा कि मौजूदा पेज, पहले से इंस्टॉल किए गए किसी ऐप्लिकेशन का है या नहीं. इससे यह पता चलेगा कि ऐसा ही है. इसका समाधान यह है कि अंदरूनी ऐप्लिकेशन को मैन्युअल तरीके से इंस्टॉल किया जाए ("शॉर्टकट बनाएं" ब्राउज़र मेन्यू विकल्प से) या बाहरी ऐप्लिकेशन से पहले, पहले अंदरूनी ऐप्लिकेशन इंस्टॉल करना.
• सूचना और Badging API: अगर आउटर ऐप्लिकेशन इंस्टॉल है, लेकिन इनर ऐप्लिकेशन नहीं है, तो इनर ऐप्लिकेशन से मिलने वाली सूचनाओं और बैज को गलत तरीके से आउटर ऐप्लिकेशन (यह इंस्टॉल किए गए ऐप्लिकेशन का सबसे नज़दीकी दायरा है) जोड़ दिया जाएगा. यह सुविधा ठीक उस स्थिति में काम करती है जहां उपयोगकर्ता के डिवाइस में दोनों ऐप्लिकेशन इंस्टॉल होते हैं.
• लिंक कैप्चर करना: आउटर ऐप्लिकेशन, इनर ऐप्लिकेशन से जुड़े यूआरएल कैप्चर कर सकता है. ऐसा खास तौर पर तब हो सकता है, जब आउटर ऐप्लिकेशन इंस्टॉल हो, लेकिन इनर ऐप्लिकेशन नहीं हो. इसी तरह, बाहरी ऐप्लिकेशन में मौजूद लिंक जो इनर ऐप्लिकेशन से लिंक करते हैं वे कैप्चर को इनर ऐप्लिकेशन में लिंक नहीं करेंगे. ऐसा इसलिए, क्योंकि उन्हें बाहरी ऐप्लिकेशन के दायरे में शामिल माना जाता है. इसके अलावा, ChromeOS और Android पर, अगर इन ऐप्लिकेशन को Play Store (भरोसेमंद वेब गतिविधियां के तौर पर) में जोड़ा जाता है, तो आउटर ऐप्लिकेशन सभी लिंक कैप्चर कर लेगा. भले ही, अंदरूनी ऐप्लिकेशन इंस्टॉल हो, फिर भी ओएस, उपयोगकर्ता को उन्हें आउटर ऐप्लिकेशन में खोलने का विकल्प देगा.

नतीजा

इस लेख में हमने उन अलग-अलग तरीकों के बारे में बताया है जिनसे डेवलपर एक ही डोमेन में एक-दूसरे से जुड़े कई प्रोग्रेसिव वेब ऐप्लिकेशन बना सकते हैं.

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

• अलग-अलग ऑरिजिन: सुझाया गया
• एक ही ऑरिजिन, ओवरलैप न होने वाले पाथ: इसका सुझाव नहीं दिया जाता
• एक ही ऑरिजिन, ओवरलैप/नेस्ट किए गए पाथ: इसका सुझाव नहीं दिया जाता

अगर अलग-अलग ऑरिजिन का इस्तेमाल नहीं किया जा सकता, तो ओवरलैप न करने वाले पाथ (जैसे, https://example.com/app1/ और https://example.com/app2/) का इस्तेमाल करने का सुझाव दिया जाता है.https://example.com/https://example.com/app/

अन्य संसाधन

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

तकनीकी समीक्षाओं और सुझावों के लिए धन्यवाद के साथ: जो मेडली, डॉमिनिक एनजी, ऐलन कटर, डैनियल मर्फ़ी, पेनी मैकलाक्लन, थॉमस स्टेनर, और डार्विन हुआंग

Unsplash पर टिम मॉसहोल्डर की फ़ोटो