सर्विस वर्कर की मानसिकता

सर्विस वर्कर के बारे में सोचते समय क्या करना चाहिए.

सर्विस वर्कर, शक्तिशाली और सीखने लायक होते हैं. इनकी मदद से, अपने उपयोगकर्ताओं को बिलकुल नया अनुभव दिया जा सकता है. आपकी साइट तुरंत लोड हो सकती है. यह ऑफ़लाइन काम कर सकता है. इसे प्लैटफ़ॉर्म के हिसाब से एक खास ऐप्लिकेशन के तौर पर इंस्टॉल किया जा सकता है और इसे बेहतर तरीके से इस्तेमाल किया जा सकता है. हालांकि, यह वेब की पहुंच और आज़ादी के हिसाब से है.

लेकिन सर्विस वर्कर, उन सभी से अलग है जो हम में से ज़्यादातर वेब डेवलपर को करते थे. इनमें आपको सीखने का एक तेज़ तरीका मिलता है. साथ ही, इनमें कुछ ऐसी चीज़ें भी आती हैं जिन पर आपको ध्यान देना चाहिए.

Google Developers और मैंने हाल ही में एक प्रोजेक्ट—सर्विस वर्कीज़—पर साथ मिलकर काम किया है. यह सर्विस वर्कर को समझने के लिए एक मुफ़्त गेम है. इसे बनाने और सर्विस वर्कर के जटिल काम करने के दौरान, मुझे कुछ समस्याएं हुईं. इससे मुझे सबसे ज़्यादा मदद मिली, इसके लिए कुछ नाटकीय रूपों को दिखाने में मदद मिली. इस पोस्ट में हम इन मानसिक मॉडलों को एक्सप्लोर करेंगे और अपने दिमाग में विरोधाभासी विशेषताओं के इर्द-गिर्द काम करेंगे, जो सर्विस वर्कर को पेचीदा और शानदार बनाते हैं.

वही, लेकिन अलग

अपने सर्विस वर्कर को कोडिंग करते समय, आपको कई चीज़ें जानी-पहचानी लगती हैं. आपको अपनी पसंदीदा नई JavaScript भाषा सुविधाओं का इस्तेमाल करने का मौका मिलता है. लाइफ़साइकल इवेंट को यूज़र इंटरफ़ेस (यूआई) इवेंट की तरह ही सुना जाता है. आपके पास ऐसे वादों की मदद से कंट्रोल फ़्लो को मैनेज करने की सुविधा होती है जिनकी आपको आदत है.

हालांकि, सर्विस वर्कर के दूसरे व्यवहार की वजह से, आपको भ्रम की स्थिति में सिर चकराने लगता है. खासकर तब, जब पेज को रीफ़्रेश करने पर आपको कोड में किए गए बदलाव नहीं दिखते.

एक नई लेयर

आम तौर पर साइट बनाते समय आपको ध्यान देने के लिए सिर्फ़ दो लेयर होती हैं: क्लाइंट और सर्वर. सर्विस वर्कर, एक नई लेयर है, जो बीच में मौजूद होती है.

सर्विस वर्कर, क्लाइंट और सर्वर के बीच बीच लेयर के तौर पर काम करता है

अपने सर्विस वर्कर के बारे में जानें. यह एक तरह का ब्राउज़र एक्सटेंशन है, जिसे आपकी साइट, उपयोगकर्ता के ब्राउज़र में इंस्टॉल कर सकती है. इंस्टॉल हो जाने के बाद, सर्विस वर्कर आपकी साइट के लिए ब्राउज़र को एक मज़बूत मिडल लेयर के साथ extends. यह सर्विस वर्कर लेयर आपकी साइट के सभी अनुरोधों को देख सकती है और उन्हें मैनेज कर सकती है.

सर्विस वर्कर लेयर की अपना लाइफ़साइकल, ब्राउज़र टैब से अलग होती है. किसी सर्विस वर्कर को अपडेट करने के लिए, पेज का रीफ़्रेश होना काफ़ी नहीं होता. ठीक उसी तरह, जैसे कि सर्वर पर डिप्लॉय किए गए कोड को अपडेट करने के लिए, पेज रीफ़्रेश होना काफ़ी नहीं होता. अपडेट करने के लिए, हर लेयर के अपने खास नियम होते हैं.

सर्विस वर्कीज़ गेम में, हमने सर्विस वर्कर के लाइफ़साइकल की कई जानकारी दी है और आपको उस पर काम करने के कई तरीके बताए हैं.

शक्तिशाली, लेकिन सीमित

अपनी साइट पर सर्विस वर्कर होने से, आपको शानदार फ़ायदे मिलते हैं. आपकी साइट ये काम कर सकती है:

सर्विस वर्कर जितना काम कर सकते हैं, वे डिज़ाइन की वजह से सीमित होते हैं. वे सिंक्रोनस या आपकी साइट वाले थ्रेड में कुछ भी नहीं कर सकते. इसका मतलब है कि आपको इनका ऐक्सेस नहीं है:

  • localStorage
  • डीओएम
  • विंडो

अच्छी खबर यह है कि आपका पेज कई तरीकों से अपने सर्विस वर्कर से संपर्क कर सकता है. इनमें सीधे postMessage, वन-टू-वन मैसेज चैनल, और एक-से-कई ब्रॉडकास्ट चैनल शामिल हैं.

लंबे समय तक ज़िंदा, लेकिन कम समय तक ज़िंदा

जब कोई उपयोगकर्ता आपकी साइट से चला जाता है या टैब बंद कर देता है, तब भी ऐक्टिव सर्विस वर्कर किसी भी स्थिति में काम करता रहता है. ब्राउज़र इस सर्विस वर्कर को आस-पास रखता है, ताकि अगली बार उपयोगकर्ता के आपकी साइट पर वापस आने पर यह तैयार रहे. पहला अनुरोध किए जाने से पहले, सर्विस वर्कर को उसे रोकने और पेज का कंट्रोल लेने का मौका मिल जाता है. इसी वजह से किसी साइट को ऑफ़लाइन काम करने की अनुमति मिलती है—सर्विस वर्कर, पेज के कैश मेमोरी में सेव किए गए वर्शन को दिखा सकता है, भले ही उपयोगकर्ता के पास इंटरनेट से कोई कनेक्शन न हो.

सर्विस वर्क्स में हम इस सिद्धांत को कोलोहे (एक दोस्ताना सर्विस वर्कर) के साथ इंटरसेप्ट करते हैं और अनुरोधों को मैनेज करते हैं.

बंद किया गया

सेवा कर्मचारी अमर होने के बावजूद, उन्हें किसी भी समय बंद किया जा सकता है. ब्राउज़र किसी ऐसे सर्विस वर्कर पर संसाधनों को बर्बाद नहीं करना चाहता जो फ़िलहाल कुछ नहीं कर रहा है. बंद करना और बंद करने का मतलब यह नहीं है कि सर्विस वर्कर इंस्टॉल और चालू रहता है. इसे अभी सुला दिया गया है. अगली बार जब भी ज़रूरत होगी (जैसे कि किसी अनुरोध को मैनेज करने के लिए), तो ब्राउज़र उसे अपने-आप चालू कर देता है.

waitUntil

बार-बार सोने की संभावना की वजह से, आपके सर्विस वर्कर को ब्राउज़र को यह बताने के लिए एक तरीके की ज़रूरत होती है कि कब वह कोई ज़रूरी काम कर रहा है और झपकी लेने का मन नहीं करता है. ऐसे में event.waitUntil() का इस्तेमाल शुरू किया जा सकता है. यह तरीका उसमें इस्तेमाल की गई लाइफ़साइकल को बढ़ा देता है. साथ ही, जब तक हम पूरी तरह तैयार नहीं हो जाते, तब तक यह प्रोसेस बंद होने और इसके लाइफ़साइकल के अगले चरण पर जाने से भी बचा रहता है. इससे हमें कैश मेमोरी सेटअप करने, नेटवर्क से रिसॉर्स फ़ेच करने वगैरह का समय मिल जाता है.

यह उदाहरण ब्राउज़र को बताता है कि जब तक assets कैश मेमोरी नहीं बन जाती और उसमें किसी तलवार की तस्वीर नहीं दिखाई जाती, तब तक हमारा सर्विस वर्कर इंस्टॉल नहीं होता:

self.addEventListener("install", event => {
  event.waitUntil(
    caches.open("assets").then(cache => {
      return cache.addAll(["/weapons/sword/blade.png"]);
    })
  );
});

दुनिया भर के राज्यों के बारे में जानें

इसके चालू/बंद होने पर सर्विस वर्कर का ग्लोबल स्कोप रीसेट हो जाता है. इसलिए, ध्यान रखें कि अपने सर्विस वर्कर में किसी ग्लोबल स्थिति का इस्तेमाल न करें, नहीं तो अगली बार इसके फिर से चालू होने पर आपको दुख होगा. इसकी स्थिति, इसकी उम्मीद से अलग होगी.

ग्लोबल स्थिति का इस्तेमाल करने वाले इस उदाहरण पर ध्यान दें:

const favoriteNumber = Math.random();
let hasHandledARequest = false;

self.addEventListener("fetch", event => {
  console.log(favoriteNumber);
  console.log(hasHandledARequest);
  hasHandledARequest = true;
});

हर अनुरोध पर यह सर्विस वर्कर एक संख्या लॉग करेगा—मान लें कि 0.13981866382421893. hasHandledARequest वैरिएबल भी true में बदल जाता है. अब सर्विस वर्कर कुछ देर के लिए निष्क्रिय रहता है, इसलिए ब्राउज़र इसे बंद कर देता है. अगली बार अनुरोध किए जाने पर, सर्विस वर्कर की फिर से ज़रूरत होती है, इसलिए ब्राउज़र उसे सक्रिय कर देता है. इसकी स्क्रिप्ट का फिर से आकलन किया जाता है. अब hasHandledARequest को false पर रीसेट कर दिया गया है और favoriteNumber कुछ पूरी तरह से अलग है—0.5907281835659033.

सर्विस वर्कर में स्टोर की गई स्थिति पर भरोसा नहीं किया जा सकता. साथ ही, Message Channels जैसी चीज़ों के इंस्टेंस बनाने से गड़बड़ियां हो सकती हैं: सर्विस वर्कर के रुकने/शुरू होने पर, आपको हर बार नया इंस्टेंस मिलेगा.

Service Workies चैप्टर 3 में, हम रोके गए सर्विस वर्कर को इस तरह से देखते हैं कि वे जागने के बाद, अपने सभी रंग खो चुके हैं.

बंद किए गए सर्विस वर्कर का विज़ुअलाइज़ेशन

साथ-साथ, लेकिन अलग

आपके पेज को एक बार में सिर्फ़ एक सर्विस वर्कर कंट्रोल कर सकता है. हालांकि, इसमें एक साथ दो सर्विस वर्कर इंस्टॉल हो सकते हैं. अपने सर्विस वर्कर कोड में बदलाव करने और पेज को रीफ़्रेश करने पर, आपको अपने सर्विस वर्कर में कोई बदलाव नहीं करना पड़ता. सर्विस वर्कर बदले नहीं जा सकते. इसके बजाय, आप एक नया कारोबार बना रहे हैं. यह नया सर्विस वर्कर (इसे SW2 कहते हैं) इंस्टॉल करेगा, लेकिन अभी चालू नहीं होगा. इसे मौजूदा सर्विस वर्कर (SW1) के खत्म होने (जब आपका उपयोगकर्ता आपकी साइट से चला जाता है) के लिए इंतज़ार करना होगा.

किसी अन्य सर्विस वर्कर के कैश मेमोरी से छेड़छाड़ करना

इंस्टॉल करते समय, SW2 ऐप्लिकेशन को सेटअप कर सकता है. आम तौर पर, कैश मेमोरी में डेटा अपने-आप भर जाता है और कैश मेमोरी में जानकारी अपने-आप भर जाती है. ध्यान दें: इस नए सर्विस वर्कर के पास उन सभी चीज़ों का ऐक्सेस है जिनका ऐक्सेस मौजूदा सर्विस वर्कर के पास है. अगर आप सावधानी नहीं बरतते हैं, तो आपका नया इंतज़ार करने वाले सर्विस वर्कर, आपके मौजूदा सर्विस वर्कर के लिए बहुत परेशान कर सकते हैं. कुछ उदाहरण, जिनसे आपको परेशानी हो सकती है:

  • SW2, उस कैश को मिटा सकता है जिसका इस्तेमाल SW1 सक्रिय रूप से कर रहा है.
  • SW2, कैश मेमोरी के उस कॉन्टेंट में बदलाव कर सकता है जिसका इस्तेमाल SW1 कर रहा है. इससे SW1 को उन एसेट के बारे में पता चलता है जिनकी पेज को उम्मीद नहीं है.

स्किप करना छोड़ें

सर्विस वर्कर, पेज के इंस्टॉल होते ही उसे कंट्रोल करने के लिए, जोखिम भरे skipWaiting() तरीके का भी इस्तेमाल कर सकता है. यह आम तौर पर एक बुरा आइडिया है, जब तक कि आप जान-बूझकर किसी बगी सर्विस वर्कर को बदलने की कोशिश न कर रहे हों. ऐसा हो सकता है कि नया सर्विस वर्कर, अपडेट किए गए ऐसे संसाधनों का इस्तेमाल कर रहा हो जिनकी उम्मीद मौजूदा पेज को नहीं है. इस वजह से, गड़बड़ियां और गड़बड़ियां हो सकती हैं.

सफ़ाई शुरू करें

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

const version = 1;
const assetCacheName = `assets-${version}`;

self.addEventListener("install", event => {
  caches.open(assetCacheName).then(cache => {
    // confidently do stuff with your very own cache
  });
});

जब किसी नए सर्विस वर्कर को डिप्लॉय किया जाता है, तो आपको version को बम्प करेंगे, ताकि यह पिछले सर्विस वर्कर से पूरी तरह अलग कैश मेमोरी के ज़रिए अपनी ज़रूरत के हिसाब से काम कर सके.

कैश मेमोरी का विज़ुअलाइज़ेशन

क्लीन करना बंद करें

जब आपका सर्विस वर्कर activated स्थिति तक पहुंच जाता है, तो आपको पता चलता है कि उसने उसे कंट्रोल कर लिया है और पिछला सर्विस वर्कर ग़ैर-ज़रूरी है. इस स्थिति में, पुराने सर्विस वर्कर के बाद सफ़ाई करना ज़रूरी है. यह न सिर्फ़ आपके उपयोगकर्ताओं के कैश स्टोरेज की सीमाओं का सम्मान करता है, बल्कि अनजाने में होने वाली गड़बड़ियों से भी बचा सकता है.

caches.match() वाला शॉर्टकट, अक्सर इस्तेमाल किया जाने वाला शॉर्टकट है. इसका इस्तेमाल, किसी भी कैश मेमोरी से किसी आइटम की जानकारी पाने के लिए किया जाता है, जहां मौजूद कॉन्टेंट से मिलता-जुलता कोई दूसरा आइटम मौजूद होता है. हालांकि, यह कैश मेमोरी में उसी क्रम में दोहराता है जिस क्रम में उन्हें बनाया गया था. मान लें कि आपके पास दो अलग-अलग कैश मेमोरी में किसी स्क्रिप्ट फ़ाइल app.js के दो वर्शन हैं—assets-1 और assets-2. आपका पेज नई स्क्रिप्ट की उम्मीद कर रहा है, जो assets-2 में सेव है. हालांकि, अगर आपने पुराना कैश नहीं मिटाया है, तो caches.match('app.js'), assets-1 से पुरानी कैश मेमोरी वापस करेगा. हो सकता है कि इससे आपकी साइट बंद हो जाए.

जब पुराने सर्विस वर्कर को किसी ऐसी कैश मेमोरी की ज़रूरत नहीं होती है, तो उसे मिटाने के बाद ही सर्विस वर्कर को हटाया जा सकता है.

const version = 2;
const assetCacheName = `assets-${version}`;

self.addEventListener("activate", event => {
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cacheName => {
          if (cacheName !== assetCacheName){
            return caches.delete(cacheName);
          }
        });
      );
    });
  );
});

अपने सर्विस वर्कर को एक-दूसरे के साथ घुसपैठ करने से रोकने में, थोड़ी मेहनत और अनुशासन में लगता है, लेकिन यह मुश्किल काम है.

सर्विस वर्कर की मानसिकता

सर्विस वर्कर के बारे में सोचकर, अपनी सोच को सही करें. इससे आपको आत्मविश्वास के साथ अपना काम करने में मदद मिलेगी. इन्हें सीख लेने के बाद, अपने उपयोगकर्ताओं को शानदार अनुभव दिया जा सकता है.

अगर आप गेम खेलकर सब कुछ समझना चाहते हैं, तो आप भाग्यशाली हैं! Service Workies पर जाएं और ऑफ़लाइन जानवरों को मारने के लिए, सर्विस वर्कर के तरीके जानें.