Featured image of post PWA (Progressive Web Apps) की संभावनाएँ और कार्यान्वयन (Service Worker की शक्ति)
फ्रंटएंड Web

PWA (Progressive Web Apps) की संभावनाएँ और कार्यान्वयन (Service Worker की शक्ति)

PWA के समग्र दृष्टिकोण से लेकर Service Worker के जीवनचक्र, ऑफ़लाइन कैशिंग और Push सूचनाओं तक का स्पष्टीकरण।

1. परिचय: PWA क्या है?

वेब तकनीक पिछले कुछ दशकों में नाटकीय रूप से विकसित हुई है। स्थिर HTML दस्तावेज़ों के लिंक संग्रह से शुरू होकर, गतिशील DOM हेरफेर, Ajax के माध्यम से एसिंक्रोनस संचार और SPA (Single Page Application) के उद्भव के माध्यम से, अब ऐसे एप्लिकेशन बनाना संभव है जो मूल (नेटिव) ऐप के समान या उससे बेहतर उपयोगकर्ता अनुभव (UX) प्रदान करते हैं। इस विकास में सबसे आगे PWA (Progressive Web Apps) हैं।

PWA, संक्षेप में, “वेब एप्लिकेशन हैं जो वेब की पहुंच और नेटिव ऐप्स के उच्च प्रदर्शन/UX को जोड़ते हैं।” पारंपरिक वेब ऐप्स के साथ, जब ऑफ़लाइन एक्सेस किया जाता है, तो “कोई इंटरनेट कनेक्शन नहीं है” त्रुटि स्क्रीन (Chrome में प्रसिद्ध डायनासोर गेम स्क्रीन) प्रदर्शित होना सामान्य था। हालाँकि, यदि PWA तकनीक को सही ढंग से लागू किया जाता है, तो ऑफ़लाइन होने पर भी ऐप को शुरू करना, कैश की गई सामग्री देखना और पृष्ठभूमि (बैकग्राउंड) में डेटा सिंक्रनाइज़ेशन जैसी प्रक्रियाएँ करना संभव हो जाता है।

यह लेख PWA के समग्र दृष्टिकोण से लेकर इसके मुख्य भाग Service Worker के जीवनचक्र, उन्नत कैश रणनीतियों, IndexedDB के साथ एकीकरण और भविष्य की संभावनाओं के बारे में अत्यधिक विस्तृत और व्यापक स्पष्टीकरण प्रदान करेगा।

2. नेटिव ऐप बनाम PWA

वेब एप्लिकेशन विकसित करते समय, बहस का एक निरंतर विषय यह है कि “क्या मुझे नेटिव ऐप या PWA को अपनाना चाहिए?” प्रत्येक के लाभों और कमियों को गहराई से समझने से आप अपनी परियोजना के लिए सर्वोत्तम तकनीक का चयन कर सकेंगे।

2.1. नेटिव ऐप्स की ताकत और कमजोरियां

नेटिव ऐप्स की सबसे बड़ी ताकत (iOS के लिए Swift/Objective-C और Android के लिए Kotlin/Java जैसी भाषाओं में विकसित ऐप्स) OS API तक पूर्ण पहुँच होना है। यह कैमरा, GPS, ब्लूटूथ, NFC और विभिन्न सेंसर का पूरी तरह से उपयोग करने वाली उन्नत सुविधाओं की अनुमति देता है। इसके अतिरिक्त, क्योंकि वे OS के लिए अनुकूलित हैं, रेंडरिंग प्रदर्शन बहुत अधिक है, जिससे नेटिव ऐप्स जटिल एनिमेशन और 3D ग्राफिक्स का भारी उपयोग करने वाले गेम के लिए अत्यधिक फायदेमंद हो जाते हैं।

दूसरी ओर, नेटिव ऐप्स में निम्नलिखित प्रमुख कमजोरियां (चुनौतियां) हैं।

  • ** विकास लागत और सीखने की लागत ** : iOS और Android के लिए अलग-अलग कोडबेस को बनाए रखने की आवश्यकता होती है (इसे React Native या Flutter जैसे क्रॉस-प्लेटफ़ॉर्म फ्रेमवर्क के साथ कम किया जा सकता है, लेकिन इसे पूरी तरह से शून्य नहीं किया जा सकता है)।
  • ** ऐप स्टोर समीक्षा ** : ऐप्स को Apple के App Store या Google Play की समीक्षा पास किए बिना जारी नहीं किया जा सकता है, और अपडेट करते समय समीक्षा के लिए कई दिनों तक प्रतीक्षा करने का समय हो सकता है।
  • ** उपयोगकर्ता अधिग्रहण बाधाएं ** : ऐप स्टोर खोलने, खोजने, डाउनलोड करने और स्थापित करने की प्रक्रिया उपयोगकर्ताओं के लिए एक बड़ी परेशानी (घर्षण) है।

2.2. PWA द्वारा हल की गई समस्याएं

PWA का उद्देश्य वेब की ताकत का लाभ उठाते हुए नेटिव ऐप्स की कमजोरियों को दूर करना है।

  • ** एक स्रोत, बहु-उपयोग ** : HTML, CSS और JavaScript जैसी वेब मानक तकनीकों के साथ विकसित एक एकल कोडबेस, ब्राउज़र से लैस सभी डिवाइस (मोबाइल, टैबलेट, डेस्कटॉप) पर चलेगा।
  • ** कोई समीक्षा आवश्यक नहीं और तत्काल अपडेट ** : चूँकि PWA केवल वेबसाइटें हैं, इसलिए उन्हें ऐप स्टोर समीक्षाओं को पास करने की आवश्यकता नहीं है। सर्वर पर फ़ाइलों को अपडेट करके, उपयोगकर्ता हमेशा नवीनतम संस्करण का उपयोग कर सकते हैं।
  • ** बिना स्थापना के निर्बाध अनुभव ** : उपयोगकर्ता केवल URL तक पहुंचकर ऐप का उपयोग शुरू कर सकते हैं। यदि वे इसे पसंद करते हैं, तो वे इसे “होम स्क्रीन पर जोड़ सकते हैं (Install)” ताकि इसे नेटिव ऐप की तरह ऐप आइकन से शुरू किया जा सके।
  • ** लिंक द्वारा साझा करने की क्षमता ** : किसी विशिष्ट स्क्रीन या स्थिति को URL के रूप में साझा करने की क्षमता वेब के लिए एक शक्तिशाली हथियार है।

बेशक, PWA की भी सीमाएं हैं। विशेष रूप से iOS (Safari) वातावरण में, Apple की नीतियों के कारण Web API का कार्यान्वयन धीमा हो जाता है, Push सूचनाओं का समर्थन हाल तक अपर्याप्त रहा है, और पृष्ठभूमि के संचालन पर सख्त प्रतिबंध हैं। हालाँकि, हाल के वर्षों में Safari ने PWA के लिए अपना समर्थन बढ़ाया है, और अंतर धीरे-धीरे कम हो रहा है।

3. PWA को बनाने वाले 3 स्तंभ

PWA को लागू करने के लिए, निम्नलिखित तीन प्रमुख तकनीकी तत्वों की आवश्यकता है।

3.1. HTTPS (सुरक्षित संचार)

PWA के शक्तिशाली फ़ंक्शन (Service Worker, Push सूचनाएँ, Geolocation आदि) सुरक्षा कारणों से केवल HTTPS वातावरण में काम करते हैं (localhost, जो एक स्थानीय विकास वातावरण है, को अपवाद के रूप में अनुमति दी गई है)। यह दुर्भावनापूर्ण तृतीय पक्षों को मध्य-में-हमले (man-in-the-middle attacks) के माध्यम से इन सुविधाओं से छेड़छाड़ या दुरुपयोग करने से रोकने के लिए है।

3.2. Web App Manifest

Web App Manifest (manifest.json) एक JSON फ़ाइल है जो ब्राउज़र को वेब ऐप के बारे में मेटाडेटा प्रदान करती है। यह ऐप के आइकन, नाम, थीम रंग, प्रदर्शन मोड आदि को परिभाषित करता है, और डिवाइस पर इंस्टॉल होने पर नेटिव-ऐप जैसी उपस्थिति को नियंत्रित करता है।

3.3. Service Worker

Service Worker ही वह जादू की छड़ी है जो PWA को केवल वेबसाइट से “एप्लिकेशन” में उन्नत करती है। यह एक JavaScript वातावरण है जिसे ब्राउज़र पृष्ठभूमि में निष्पादित करता है और वेब पेज से अलग थ्रेड पर संचालित होता है। यह नेटवर्क अनुरोधों (प्रॉक्सी) को रोक सकता है, कैश का प्रबंधन कर सकता है, और Push सूचनाएं प्राप्त कर सकता है।

4. Web App Manifest का विस्तृत विन्यास

Web App Manifest, PWA का चेहरा बताने वाली कॉन्फ़िगरेशन फ़ाइल है। यह निर्धारित करता है कि जब उपयोगकर्ता ऐप इंस्टॉल करता है तो वह कैसा दिखता है और कैसा व्यवहार करता है।

नीचे एक विशिष्ट manifest.json विन्यास का उदाहरण दिया गया है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "name": "प्रोग्रेसिव वेब ऐप उदाहरण",
  "short_name": "पीडब्ल्यूए उदाहरण",
  "description": "प्रोग्रेसिव वेब ऐप का एक व्यापक उदाहरण।",
  "start_url": "/?source=pwa",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0055ff",
  "icons": [
    {
      "src": "/images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png",
      "purpose": "any maskable"
    },
    {
      "src": "/images/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "orientation": "portrait",
  "scope": "/"
}

प्रमुख गुणों का स्पष्टीकरण

  • name और short_name : स्थापना प्रॉम्प्ट और होम स्क्रीन पर ऐप आइकन के नीचे प्रदर्शित होने वाले नाम। सीमित स्थान वाली होम स्क्रीन पर short_name को प्राथमिकता दी जाती है।
  • start_url : वह URL जो तब लोड होता है जब उपयोगकर्ता पहली बार होम स्क्रीन आइकन से ऐप लॉन्च करता है। ट्रैकिंग पैरामीटर (उदाहरण: ?source=pwa) जोड़कर, एक्सेस एनालिटिक्स टूल के साथ PWA से एक्सेस को अलग करना संभव हो जाता है।
  • display : ऐप का डिस्प्ले मोड निर्दिष्ट करता है।
    • standalone : ब्राउज़र UI (URL बार, बैक बटन आदि) को पूरी तरह से छुपाता है और इसे नेटिव ऐप की तरह प्रदर्शित करता है। यह सबसे अनुशंसित सेटिंग है।
    • fullscreen : संपूर्ण स्क्रीन का उपयोग करता है और यहां तक कि स्टेटस बार को भी छुपाता है (गेम और वीडियो ऐप के लिए आदर्श)।
    • minimal-ui : केवल बुनियादी नेविगेशन UI प्रदर्शित करता है।
    • browser : सामान्य ब्राउज़र टैब के रूप में प्रदर्शित होता है।
  • theme_color और background_color : ऐप के थीम रंग और स्टार्टअप पर स्प्लैश स्क्रीन की पृष्ठभूमि का रंग परिभाषित करता है।
  • icons : ऐप आइकन के रूप में उपयोग की जाने वाली छवियों की एक सरणी। विभिन्न डिवाइस रिज़ॉल्यूशन का समर्थन करने के लिए एकाधिक आकार (कम से कम 192x192 और 512x512) प्रदान करने की अनुशंसा की जाती है। purpose: "maskable" निर्दिष्ट करके, आप Android आदि पर आइकन क्रॉपिंग को अनुकूलित कर सकते हैं।

5. Service Worker का मुख्य भाग और जीवनचक्र

Service Worker वह है जिसे PWA का “हृदय” कहा जाना चाहिए। पारंपरिक वेब पेजों के भीतर निष्पादित JavaScript के विपरीत, इसके पास DOM तक पहुंच नहीं है। इसके बजाय, यह नेटवर्क अनुरोधों में मध्यस्थता करता है, कैश में हेरफेर करता है, और पृष्ठभूमि (बैकग्राउंड) सिंक प्रक्रियाएं करता है।

5.1. Service Worker का जीवनचक्र

Service Worker का पेज से स्वतंत्र अपना जीवनचक्र होता है। इस जीवनचक्र को सही ढंग से समझना अप्रत्याशित कैश समस्याओं को रोकने की कुंजी है (जैसे अपडेट के बाद स्क्रीन नहीं बदलना)।

निम्नलिखित Mermaid आरेख Service Worker के राज्य संक्रमण (स्थिति परिवर्तन) को दर्शाता है।

  stateDiagram-v2
    direction TB
    "पार्स किया गया (Parsed)" --> "स्थापित हो रहा है (Installing)" : "पंजीकरण (Registration)"
    "स्थापित हो रहा है (Installing)" --> "स्थापित (प्रतीक्षारत) (Installed (Waiting))" : "सफलता (Success)"
    "स्थापित हो रहा है (Installing)" --> "अनावश्यक (Redundant)" : "त्रुटि (Error)"
    "स्थापित (प्रतीक्षारत) (Installed (Waiting))" --> "सक्रिय हो रहा है (Activating)" : "सभी क्लाइंट बंद / skipWaiting()"
    "सक्रिय हो रहा है (Activating)" --> "सक्रिय (Activated)" : "सफलता (Success)"
    "सक्रिय हो रहा है (Activating)" --> "अनावश्यक (Redundant)" : "त्रुटि (Error)"
    "सक्रिय (Activated)" --> "अनावश्यक (Redundant)" : "नए SW द्वारा प्रतिस्थापित (Replaced by new SW)"
  1. पार्स किया गया (Parsed) : वह स्थिति जब ब्राउज़र Service Worker स्क्रिप्ट डाउनलोड कर लेता है और पार्सिंग (विश्लेषण) समाप्त कर लेता है।
  2. स्थापित हो रहा है (Installing) : वह स्थिति जब install घटना (इवेंट) सक्रिय हो जाती है। इस चरण का उपयोग मुख्य रूप से एप्लिकेशन के संचालन के लिए आवश्यक स्थिर संपत्तियों (HTML, CSS, JS, चित्र आदि) को कैश (प्री-कैशिंग) करने के लिए किया जाता है। यदि स्थापना विफल हो जाती है (उदाहरण के लिए, कैश सहेजने में विफलता), तो Service Worker नष्ट हो जाता है।
  3. स्थापित / प्रतीक्षारत (Installed / Waiting) : स्थापना पूर्ण हो गई है, लेकिन पुराना Service Worker अभी भी अन्य टैब में सक्रिय रूप से चल रहा है, इसलिए यह बदलने की प्रतीक्षा कर रहा है। उपयोगकर्ता द्वारा सभी टैब बंद करके फिर से खोलने या self.skipWaiting() कॉल करने पर यह अगले चरण पर आगे बढ़ता है।
  4. सक्रिय हो रहा है (Activating) : वह स्थिति जब activate घटना (इवेंट) सक्रिय हो जाती है। इस चरण का उपयोग मुख्य रूप से पुराने Service Worker द्वारा बनाए गए अनावश्यक कैश को हटाने और सफाई (क्लीनअप) करने के लिए किया जाता है।
  5. सक्रिय (Activated) : पूरी तरह से चालू स्थिति, जहां यह पेज से fetch इवेंट या push इवेंट को नियंत्रित और संसाधित कर सकता है।
  6. अनावश्यक (Redundant) : वह स्थिति जब स्थापना विफल हो गई, सक्रियण विफल हो गया, या इसे Service Worker के नए संस्करण से बदल दिया गया हो।

5.2. Service Worker का पंजीकरण

Service Worker का उपयोग करने के लिए, आपको पहले मुख्य JavaScript थ्रेड से पंजीकरण प्रक्रिया करनी होगी।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// main.js या index.html के <script> में
if ("serviceWorker" in navigator) {
  window.addEventListener("load", () => {
    navigator.serviceWorker
      .register("/sw.js", { scope: "/" })
      .then((registration) => {
        console.log("ServiceWorker पंजीकरण सफल रहा, स्कोप: ", registration.scope);
      })
      .catch((error) => {
        console.error("ServiceWorker पंजीकरण विफल रहा: ", error);
      });
  });
}

यहां जो बात महत्वपूर्ण है वह Service Worker का दायरा (स्कोप) है। डिफ़ॉल्ट रूप से, यह केवल उस निर्देशिका के नीचे के अनुरोधों को रोकता है जहां Service Worker फ़ाइल स्थित है। दूसरे शब्दों में, यदि यह /sw.js है, तो यह पूरी साइट के लिए / के अनुरोधों को रोक सकता है, लेकिन यदि इसे /js/sw.js में रखा गया है, तो यह केवल /js/ के नीचे के अनुरोधों को रोक सकता है।

6. कैश रणनीति की संपूर्ण मार्गदर्शिका

Service Worker का सबसे अच्छा हिस्सा यह है कि यह नेटवर्क अनुरोधों (fetch इवेंट) को हुक कर सकता है और आपकी अपनी कैश रणनीति लागू कर सकता है। संसाधन के प्रकार (छवि, API प्रतिक्रिया, HTML) और एप्लिकेशन की आवश्यकताओं के आधार पर उचित कैश रणनीतियों का उपयोग करना आवश्यक है।

6.1. कैश फर्स्ट (Cache First)

यह सबसे बुनियादी और तेज़ रणनीति है। पहले कैश की जाँच करें, अगर यह मौजूद है, तो इसे वापस करें, अगर यह मौजूद नहीं है, तो नेटवर्क पर जाएँ, और परिणाम को कैश में सहेजें। यह बार-बार न बदलने वाले स्थिर संसाधनों जैसे चित्र फ़ाइलों और फ़ॉन्ट के लिए आदर्श है।

  flowchart TD
    "पृष्ठ (Page)" -->|"1. अनुरोध (Request)"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -->|"2. कैश जांचें (Check Cache)"| "कैश (Cache)"
    "कैश (Cache)" -->|"3a. कैश हिट (Cache Hit)"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -->|"4a. प्रतिक्रिया (Response)"| "पृष्ठ (Page)"
    "कैश (Cache)" -->|"3b. कैश मिस (Cache Miss)"| "नेटवर्क (Network)"
    "नेटवर्क (Network)" -->|"4b. प्रतिक्रिया (Response)"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -->|"5b. कैश में सहेजें (Save to Cache)"| "कैश (Cache)"
    "सर्विस वर्कर (Service Worker)" -->|"6b. प्रतिक्रिया (Response)"| "पृष्ठ (Page)"

6.2. नेटवर्क फर्स्ट (Network First)

यह एक रणनीति है जो हमेशा नवीनतम डेटा प्राप्त करने को प्राथमिकता देती है। पहले नेटवर्क पर एक अनुरोध भेजा जाता है, और यदि सफल होता है, तो परिणाम कैश में सहेजा जाता है और पृष्ठ पर वापस आ जाता है। यह केवल ऑफ़लाइन स्थिति आदि के कारण नेटवर्क संचार विफल होने पर कैश पर वापस आ जाता है। यह बार-बार अपडेट होने वाले लेख डेटा या API प्रतिक्रियाओं के लिए उपयुक्त है।

  flowchart TD
    "पृष्ठ (Page)" -->|"1. अनुरोध (Request)"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -->|"2. प्राप्त करें (Fetch)"| "नेटवर्क (Network)"
    "नेटवर्क (Network)" -->|"3a. सफलता (Success)"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -->|"4a. कैश में सहेजें (Save to Cache)"| "कैश (Cache)"
    "सर्विस वर्कर (Service Worker)" -->|"5a. प्रतिक्रिया (Response)"| "पृष्ठ (Page)"
    "नेटवर्क (Network)" -->|"3b. त्रुटि / ऑफ़लाइन (Error / Offline)"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -->|"4b. कैश जांचें (Check Cache)"| "कैश (Cache)"
    "कैश (Cache)" -->|"5b. कैश हिट (Cache Hit)"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -->|"6b. फ़ॉलबैक प्रतिक्रिया (Fallback Response)"| "पृष्ठ (Page)"

6.3. Stale-while-revalidate (पुराना कैश लौटाएं और पृष्ठभूमि में अपडेट करें)

यह एक बहुत शक्तिशाली और आधुनिक रणनीति है जो गति और ताजगी को संतुलित करती है। जब कोई अनुरोध होता है, तो वह तुरंत कैश (पुराना या Stale डेटा) वापस कर देता है और स्क्रीन को तेज़ी से प्रस्तुत करता है। उसी समय, यह पृष्ठभूमि में (while-revalidate) नेटवर्क को एक अनुरोध भेजता है, नवीनतम डेटा प्राप्त करता है, और कैश को अपडेट करता है। उपयोगकर्ता अगली बार पहुँचने पर नवीनतम डेटा देखेंगे।

  flowchart TD
    "पृष्ठ (Page)" -->|"1. अनुरोध (Request)"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -->|"2. कैश जांचें (Check Cache)"| "कैश (Cache)"
    "कैश (Cache)" -->|"3. कैश हिट (तेज़ प्रतिक्रिया) (Cache Hit (Fast Response))"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -->|"4. पुरानी प्रतिक्रिया लौटाएं (Return Stale Response)"| "पृष्ठ (Page)"
    "सर्विस वर्कर (Service Worker)" -.->|"5. प्राप्त करें (पृष्ठभूमि) (Fetch (Background))"| "नेटवर्क (Network)"
    "नेटवर्क (Network)" -.->|"6. नेटवर्क प्रतिक्रिया (Network Response)"| "सर्विस वर्कर (Service Worker)"
    "सर्विस वर्कर (Service Worker)" -.->|"7. कैश अपडेट करें (Update Cache)"| "कैश (Cache)"

6.4. केवल कैश (Cache Only) / केवल नेटवर्क (Network Only)

  • केवल कैश (Cache Only) : यह प्रतिक्रिया पूरी तरह से केवल कैश से देता है। यदि यह मौजूद नहीं है, तो त्रुटि होगी। इसका उपयोग केवल विशिष्ट संपत्तियों (एसेट्स) के लिए किया जाता है जिनके लिए पहले से डाउनलोड होने की गारंटी होती है।
  • केवल नेटवर्क (Network Only) : यह कैश को बिल्कुल नहीं देखता और हमेशा नेटवर्क से अनुरोध करता है। इसका उपयोग उन संचारों के लिए किया जाता है जिन्हें कैश नहीं किया जाना चाहिए, जैसे प्रमाणीकरण API या POST अनुरोध।

7. Service Worker का कार्यान्वयन उदाहरण (कोड का विवरण)

अब, उपर्युक्त जीवनचक्र और कैश रणनीतियों के आधार पर वास्तविक sw.js (Service Worker फ़ाइल) का एक कार्यान्वयन उदाहरण देखें।

7.1. इंस्टालेशन इवेंट और प्री-कैश

install ईवेंट में, हम ऐप के शेल (बुनियादी HTML, CSS, JS) को पहले से कैश करते हैं। यह सुनिश्चित करता है कि ऐप का ढांचा अगली बार एक्सेस किए जाने पर या ऑफ़लाइन होने पर तुरंत प्रदर्शित किया जा सके।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// sw.js
const CACHE_NAME = "pwa-cache-v1";
const PRECACHE_URLS = [
  "/",
  "/index.html",
  "/css/style.css",
  "/js/app.js",
  "/images/logo.png",
  "/offline.html"
];

self.addEventListener("install", (event) => {
  console.log("[ServiceWorker] इंस्टॉल ईवेंट");
  
  // self.skipWaiting() कॉल करने से, आप प्रतीक्षा स्थिति को छोड़ सकते हैं और इसे तुरंत सक्रिय कर सकते हैं।
  self.skipWaiting();

  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      console.log("[ServiceWorker] ऑफ़लाइन पेजों की प्री-कैशिंग");
      return cache.addAll(PRECACHE_URLS);
    })
  );
});

7.2. सक्रिय (Activate) ईवेंट और कैश सफाई

जब कैश नाम का संस्करण (उदाहरण: pwa-cache-v1 से v2) बदला जाता है, तो स्टोरेज बचाने के लिए पुराने अनावश्यक कैश को हटाना आवश्यक है। यह activate ईवेंट में किया जाता है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

self.addEventListener("activate", (event) => {
  console.log("[ServiceWorker] सक्रिय ईवेंट");
  
  // self.clients.claim() वर्तमान में खुले सभी पृष्ठों को तुरंत नियंत्रण में ले लेता है।
  event.waitUntil(self.clients.claim());

  event.waitUntil(
    caches.keys().then((cacheNames) => {
      return Promise.all(
        cacheNames.map((cacheName) => {
          if (cacheName !== CACHE_NAME) {
            console.log("[ServiceWorker] पुराना कैश हटाया जा रहा है:", cacheName);
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

7.3. Fetch ईवेंट को संभालना

यह एक उन्नत कार्यान्वयन उदाहरण है जो fetch इवेंट को हुक करता है और अनुरोधित संसाधन प्रकार के आधार पर रणनीति बदलता है। प्रक्रियाएं विभाजित हैं ताकि छवियों में कैश फर्स्ट हो, और HTML नेविगेशन अनुरोधों में फ़ॉलबैक के साथ नेटवर्क फर्स्ट हो।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

self.addEventListener("fetch", (event) => {
  const request = event.request;
  const url = new URL(request.url);

  // POST अनुरोध या बाहरी डोमेन के अनुरोधों को नेटवर्क पर जाने दें
  if (request.method !== "GET") return;

  // HTML अनुरोध (पेज नेविगेशन) नेटवर्क फर्स्ट रणनीति + ऑफ़लाइन फ़ॉलबैक हैं
  if (request.mode === "navigate" || request.headers.get("accept").includes("text/html")) {
    event.respondWith(
      fetch(request)
        .then((response) => {
          return caches.open(CACHE_NAME).then((cache) => {
            cache.put(request, response.clone());
            return response;
          });
        })
        .catch(() => {
          // नेटवर्क त्रुटि (ऑफ़लाइन) होने पर कैश से प्राप्त करें, यदि नहीं है तो एक समर्पित ऑफ़लाइन पृष्ठ लौटाएं
          return caches.match(request).then((cachedResponse) => {
            return cachedResponse || caches.match("/offline.html");
          });
        })
    );
    return;
  }

  // छवियों जैसी स्थिर संपत्तियों के लिए कैश फर्स्ट रणनीति
  if (url.pathname.match(/\.(png|jpg|jpeg|gif|svg|css|js)$/)) {
    event.respondWith(
      caches.match(request).then((cachedResponse) => {
        if (cachedResponse) {
          return cachedResponse;
        }
        return fetch(request).then((networkResponse) => {
          return caches.open(CACHE_NAME).then((cache) => {
            cache.put(request, networkResponse.clone());
            return networkResponse;
          });
        });
      })
    );
    return;
  }

  // अन्य API अनुरोधों आदि पर Stale-while-revalidate लागू करें
  event.respondWith(
    caches.match(request).then((cachedResponse) => {
      const fetchPromise = fetch(request).then((networkResponse) => {
        return caches.open(CACHE_NAME).then((cache) => {
          cache.put(request, networkResponse.clone());
          return networkResponse;
        });
      });
      // यदि कैश मौजूद है, तो इसे पहले वापस करें, और पृष्ठभूमि में प्राप्त करना (फ़ेच) जारी रखें। यदि कोई कैश नहीं है तो fetchPromise की प्रतीक्षा करें।
      return cachedResponse || fetchPromise;
    })
  );
});

8. IndexedDB के साथ एकीकरण: अधिक उन्नत डेटा प्रबंधन

Service Worker का caches API (Cache Storage) पूर्ण HTTP प्रतिक्रियाओं (HTML फ़ाइलें, चित्र, CSS, आदि) को संग्रहीत करने के लिए बहुत उपयुक्त है। हालाँकि, यह अनुप्रयोगों द्वारा प्रबंधित संरचित डेटा (JSON प्रारूप में API प्रतिक्रियाएँ, उपयोगकर्ता सेटिंग्स डेटा, ऑफ़लाइन पोस्ट किया गया टेक्स्ट डेटा आदि) को प्रबंधित करने के लिए अपर्याप्त हो सकता है।

यहीं पर IndexedDB आता है।

IndexedDB ब्राउज़र में निर्मित एक एसिंक्रोनस ट्रांजैक्शनल NoSQL डेटाबेस है। यह बड़ी मात्रा में डेटा संग्रहीत कर सकता है और जटिल इंडेक्स खोजों की अनुमति देता है।

8.1. केवल Cache Storage अपर्याप्त क्यों है?

उदाहरण के लिए, मान लें कि आप ऑफ़लाइन होने पर ToDo ऐप में एक नया कार्य (टास्क) जोड़ते हैं। इस समय, Cache Storage में “टास्क जोड़ने के लिए POST अनुरोध” को सहेजना मुश्किल है। ऐसी आवश्यकताओं के लिए जहां ऑफ़लाइन क्रियाओं को सहेजा जाता है और ऑनलाइन लौटने पर फिर से भेजा जाता है, आपको एक सहयोग की आवश्यकता होती है जहां कार्य डेटा अस्थायी रूप से IndexedDB में सहेजा जाता है, और पृष्ठभूमि सिंक्रनाइज़ेशन (बाद में वर्णित) के समय, डेटा डेटाबेस से पुनर्प्राप्त किया जाता है और API को भेजा जाता है।

8.2. Service Worker के भीतर IndexedDB का उपयोग

Service Worker के दायरे से भी IndexedDB तक पहुँचना संभव है। चूंकि IndexedDB API को सीधे मैनिपुलेट करना बोझिल हो सकता है, इसलिए Google द्वारा प्रदान की गई idb नामक हल्की रैपर लाइब्रेरी का उपयोग करना आम बात है।

अत्यधिक उन्नत ऑफ़लाइन क्षमताओं वाले PWA में, जहाँ API से प्राप्त लेखों की सूची JSON को कैश API के बजाय IndexedDB में सहेजा जाता है और विस्तृत प्रबंधन/क्वेरी की जाती है, यह IndexedDB एक महत्वपूर्ण भूमिका निभाता है।

9. Push सूचनाएं और बैकग्राउंड सिंक (Background Sync)

जिन विशेषताओं के लिए PWA नेटिव ऐप्स के सबसे करीब आते हैं वे हैं Push सूचनाएं और बैकग्राउंड ऑपरेशंस।

9.1. Web Push API

Web Push एक ऐसा तंत्र है जो सर्वर को Service Worker को सक्रिय करने और उपयोगकर्ता को सूचनाएं देने की अनुमति देता है, भले ही ऐप खुला न हो।

  1. ** सदस्यता (Subscribe)** : ब्राउज़र की ओर से, हम उपयोगकर्ता से सूचनाओं की अनुमति मांगते हैं, Push सेवा सदस्यता जानकारी (एंडपॉइंट और एन्क्रिप्शन कुंजी) प्राप्त करते हैं, और इसे अपने स्वयं के सर्वर पर सहेजते हैं।
  2. ** भेजें (Push)** : हम अपने स्वयं के सर्वर से ब्राउज़र विक्रेता की Push सेवा (FCM या Apple Push Notification service) को एक संदेश भेजते हैं।
  3. ** प्राप्त करें (Push Event)** : जब Push सेवा डिवाइस को डेटा भेजती है, तो ब्राउज़र पृष्ठभूमि में Service Worker शुरू करता है और push ईवेंट को ट्रिगर करता है। Service Worker self.registration.showNotification() विधि को कॉल करता है और OS नेटिव अधिसूचना UI प्रदर्शित करता है।
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

self.addEventListener("push", (event) => {
  const data = event.data ? event.data.json() : {};
  const title = data.title || "नया संदेश आया है";
  const options = {
    body: data.body || "कृपया जांचने के लिए ऐप खोलें।",
    icon: "/images/icons/icon-192x192.png",
    badge: "/images/icons/badge.png",
  };

  event.waitUntil(self.registration.showNotification(title, options));
});

9.2. Background Sync (बैकग्राउंड सिंक)

मान लीजिए कि कोई उपयोगकर्ता ऑफ़लाइन सबवे (भूमिगत ट्रेन) में संदेश भेजने वाले बटन को दबाता है। सामान्य वेब ऐप्स के साथ, इसके परिणामस्वरूप त्रुटि होगी, लेकिन Background Sync API का उपयोग करके, ब्राउज़र “नेटवर्क कनेक्शन वापस आने के समय” की प्रतीक्षा करेगा और Service Worker में sync ईवेंट को ट्रिगर करेगा।

ऐप की ओर से ऑफ़लाइन डेटा को अस्थायी रूप से IndexedDB में सहेजा जाता है, और Service Worker में एक सिंक कार्य पंजीकृत किया जाता है (registration.sync.register('send-messages'))। उसके बाद, যখন आप वापस ऑनलाइन आते हैं और sync ईवेंट ट्रिगर होता है, तो यह IndexedDB से डेटा प्राप्त करता है और उसे सर्वर पर भेजता है। यह उपयोगकर्ताओं को नेटवर्क की स्थिति के बारे में चिंता किए बिना ऐप का उपयोग जारी रखने की अनुमति देता है।

10. PWA का भविष्य और चुनौतियाँ (Project Fugu के माध्यम से विकास)

PWA आज भी विकसित हो रहे हैं। विशेष रूप से, Google, Microsoft, Intel आदि के नेतृत्व में Project Fugu (Web Capabilities) नामक पहल वेब और नेटिव के बीच की सीमा को और भी धुंधला कर रही है।

Project Fugu का लक्ष्य वेब को OS के शक्तिशाली कार्यों तक सुरक्षित रूप से पहुंचने में सक्षम बनाना है जो पहले केवल नेटिव ऐप्स के लिए ही उपलब्ध थे। नतीजतन, निम्नलिखित जैसे नए API एक के बाद एक ब्राउज़रों में लागू किए जा रहे हैं।

  • Web Bluetooth API : IoT उपकरणों के साथ सीधा संचार
  • Web USB API / Web Serial API : विशेष हार्डवेयर से कनेक्शन
  • File System Access API : उपयोगकर्ता के स्थानीय फ़ाइल सिस्टम पर फ़ाइलों को सीधे पढ़ना और लिखना (IDE और संपादक PWA के लिए महत्वपूर्ण)
  • Contact Picker API : डिवाइस के संपर्क पुस्तिका डेटा तक पहुंच
  • Web Share Target API : PWA को OS के “शेयर मेनू” गंतव्य के रूप में पंजीकृत करें

चुनौतियों के रूप में, Apple (iOS/Safari) की समर्थन स्थिति का अभी भी उल्लेख किया जाता है। गोपनीयता, सुरक्षा और App Store व्यवसाय मॉडल से संबंधित चिंताओं के कारण Apple कई Project Fugu API के प्रति सतर्क रहा है। हालाँकि, यह भी सच है कि वे उपयोगकर्ताओं की मजबूत मांगों के जवाब में धीरे-धीरे PWA समर्थन बढ़ा रहे हैं, जैसे iOS 16.4 में Web Push समर्थन।

भविष्य के वेब एप्लिकेशन विकास में, PWA केवल एक विकल्प नहीं होगा, बल्कि उपयोगकर्ताओं को सर्वोत्तम अनुभव प्रदान करने के लिए एक आवश्यक तकनीकी मानक (बेसलाइन) बन जाएगा।

11. निष्कर्ष

इस लेख में, हमने PWA की बुनियादी अवधारणाओं से लेकर Service Worker के जटिल जीवनचक्र, विविध कैश रणनीतियों, IndexedDB के साथ एकीकरण और नवीनतम वेब प्रौद्योगिकी रुझानों तक बहुत गहरे स्तर पर विस्तृत जानकारी प्रदान की है।

जब आप पहली बार Service Worker के संपर्क में आते हैं तो इसकी एसिंक्रोनस प्रकृति और कैश व्यवहार से भ्रमित हो सकते हैं। हालाँकि, जीवनचक्र को सही ढंग से समझकर और उचित कैश रणनीति चुनकर और लागू करके, आप एक आश्चर्यजनक रूप से तेज़ और लचीला (resilient) वेब एप्लिकेशन बना सकते हैं।

“ऑफ़लाइन होने पर भी काम करना” का अनुभव उपयोगकर्ताओं के लिए केवल एक सुविधाजनक सुविधा से कहीं अधिक है, यह एप्लिकेशन में गहरा विश्वास और लगाव पैदा करता है। हर संभव तरीके से, अपनी परियोजनाओं में PWA तकनीक को अपनाएं और वेब की संभावनाओं को अधिकतम करें।

comments powered by Disqus