सर्विस वर्कर डेवलपमेंट के अनुभव में सुधार करना

सर्विस वर्कर का लाइफ़साइकल, किसी अनुमानित इंस्टॉलेशन और अपडेट की प्रोसेस को पक्का करता है. तो लोकल डेवलपमेंट साइकल को थोड़ा और जटिल बनाया जा सकता है.

सामान्य लोकल डेवलपमेंट साइकल में, डेवलपर टेक्स्ट एडिटर में फ़ाइलों में किए गए बदलावों को सेव करते हैं, फिर बदलावों की पुष्टि करने के लिए ब्राउज़र पर स्विच करें और यह प्रोसेस दोहराई जाती है. जब कोई सर्विस वर्कर मिक्स में होता है, तो यह चक्र काफ़ी हद तक एक जैसा होता है. हालांकि, डेवलपर की उम्मीद और ब्राउज़र के काम करने के तरीके में कुछ अंतर हो सकते हैं.

लोकल डेवलपमेंट से जुड़े अपवाद

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

हालांकि, डेवलपर के लिए यह सामान्य बात नहीं है कि वे localhost के अलावा लोकल होस्टनेम की जानकारी देंगे होस्ट की फ़ाइल. जब एक से ज़्यादा प्रोजेक्ट के लिए अलग-अलग होस्टनेम की ज़रूरत होती है, तब लोकल डेवलपमेंट एनवायरमेंट में इसकी ज़रूरत होती है. ऐसे मामलों में, खुद हस्ताक्षर किए गए सर्टिफ़िकेट का प्रावधान किया जा सकता है.

ब्राउज़र को सर्विस वर्कर टेस्टिंग के लिए अपवाद बनाने का निर्देश देना, एक ज़्यादा आसान समाधान है. Chrome के लिए, chrome://flags/#unsafely-treat-insecure-origin-as-secure पर जाएं और उसे सुरक्षित ऑरिजिन मानने के लिए असुरक्षित ऑरिजिन की जानकारी दें. Firefox about:config में devtools.serviceWorkers.testing.enabled सेटिंग के ज़रिए, असुरक्षित ऑरिजिन पर सर्विस वर्कर की जांच करने का तरीका उपलब्ध कराता है.

सर्विस वर्कर के विकास में मदद करने वाली सुविधाएं

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

अब तक सर्विस वर्कर को आज़माने का सबसे असरदार तरीका, निजी ब्राउज़िंग विं���� ��र भरोसा करना है, जैसे कि Chrome में गुप्त विंडो, या Firefox की निजी ब्राउज़िंग सुविधा का इस्तेमाल करें. निजी ब्राउज़िंग विंडो खोलने पर, हर बार नई शुरुआत की जाती है. कोई भी सक्रिय सर्विस वर्कर मौजूद नहीं है और कोई भी चालू Cache इंस्टेंस मौजूद नहीं है. इस तरह की टेस्टिंग के लिए रूटीन यह है:

1. निजी ब्राउज़िंग विंडो खोलें.
2. सर्विस वर्कर को रजिस्टर करने वाले पेज पर जाएं.
3. पुष्टि करें कि सर्विस वर्कर आपकी उम्मीद के मुताबिक काम करे.
4. गुप्त विंडो बंद करें.
5. दोहराएं.

इस प्रोसेस का इस्तेमाल करके, सर्विस वर्कर के लाइफ़साइकल की पूरी कोशिश की जा रही है.

Chrome DevTools ऐप्लिकेशन पैनल में उपलब्ध अन्य टेस्टिंग टूल मदद कर सकते हैं—हालांकि, वे सर्विस वर्कर के लाइफ़साइकल में कुछ तरीके से बदलाव कर सकते हैं.

ऐप्लिकेशन पैनल में सर्विस वर्कर लेबल वाला एक सबपैनल होता है, जो मौजूदा पेज के लिए ऐक्टिव सर्विस वर्कर को दिखाता है. हर सक्रिय सर्विस वर्कर को मैन्युअल रूप से अपडेट किया जा सकता है या पूरी तरह से रजिस्टर भी किया जा सकता है. सबसे ऊपर मौजूद तीन टॉगल भी होते हैं, जो डेवलपमेंट में मदद करते हैं.

1. ऑफ़लाइन मोड, ऑफ़लाइन स्थितियों की नकल करता है. इससे यह जांच करने में मदद मिलती है कि कोई ऐक्टिव सर्विस वर्कर, ऑफ़लाइन कॉन्टेंट दिखा रहा है या नहीं.
2. फिर से लोड करने पर अपडेट: टॉगल करने पर, पेज को किसी भी समय फिर से लोड करने पर मौजूदा सर्विस वर्कर को फिर से फ़ेच करता है और बदल देता है.
3. नेटवर्क के लिए बायपास, टॉगल करने पर सर्विस वर्कर के fetch इवेंट में किसी भी कोड को गच्चा देता है और हमेशा नेटवर्क से कॉन्टेंट फ़ेच करता है.

ये टॉगल काम के हैं. खास तौर पर, नेटवर्क के लिए बायपास करते हैं, यह तब बहुत अच्छा होता है, जब किसी ऐक्टिव सर्विस वर्कर के साथ कोई प्रोजेक्ट बनाया जा रहा हो. साथ ही, यह भी पक्का करना चाहते हों कि सर्विस वर्कर के बिना, उपयोगकर्ता उम्मीद के मुताबिक काम करें.

Firefox के डेवलपर टूल में एक मिलता-जुलता ऐप्लिकेशन पैनल होता है, लेकिन काम की क्षमता यह दिखाने तक सीमित है कि कौनसे सर्विस वर्कर इंस्टॉल किए गए हैं, और साथ ही वर्तमान पेज के लिए किसी सक्रिय सर्विस वर्कर का मैन्युअल रूप से अपंजीकृत करने की क्षमता. यह सुविधा उतनी ही मददगार है, लेकिन इसके लिए लोकल डेवलपमेंट साइकल में ज़्यादा मैन्युअल तरीके से काम करने की ज़रूरत होती है.

शिफ़्ट और फिर से लोड करें

रीफ़्रेश करने पर अपडेट या नेटवर्क को बायपास करने वाली सुविधा की ज़रूरत के बिना, किसी चालू सर्विस वर्कर के साथ स्थानीय तौर पर डेवलप करते समय, Shift को दबाकर रखना और रीफ़्रेश करें बटन को दबाना भी मददगार होता है.

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

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

कैश मेमोरी में मौजूद कॉन्टेंट की जांच करना

अगर कैश की जांच न की जा सकती हो, तो यह कहना मुश्किल है कि कैश मेमोरी की रणनीति उम्मीद के मुताबिक काम कर रही है या नहीं. ठीक है, कैश मेमोरी की जांच कोड में की जा सकती है, लेकिन यह डीबगर और/या console स्टेटमेंट वाली ऐसी प्रक्रिया है जिसमें विज़ुअल टूल इस काम के लिए बेहतर होगा. Chrome DevTools के ऐप्लिकेशन पैनल में एक सबपैनल उपलब्ध है. इसकी मदद से, Cache इंस्टेंस के कॉन्टेंट की जांच की जा सकती है.

यह सबपैनल, सर्विस वर्कर के विकास को आसान बनाता है. इसमें ये सुविधाएं मिलती हैं:

• Cache इंस्टेंस के नाम देखें.
• कैश मेमोरी में सेव की गई ऐसेट के रिस्पॉन्स वाले मुख्य हिस्से और उनसे जुड़े रिस्पॉन्स हेडर की जांच करने की सुविधा.
• कैश मेमोरी से एक या उससे ज़्यादा आइटम हटाएं या Cache के सभी इंस्टेंस मिटाएं.

इस ग्राफ़िकल यूज़र इं��रफ़ेस से सर्विस वर्कर कैश की जांच करने में आसानी होती है. इससे यह पता चलता है कि सर्विस वर्कर कैश में आइटम जोड़े, अपडेट किए गए या पूरी तरह से हटाए गए हैं या नहीं. Firefox इसी तरह की सुविधा वाले अपने कैश व्यूअर की सुविधा देता है, हालांकि यह एक अलग स्टोरेज पैनल में मौजूद होता है.

स्टोरेज कोटा को सिम्युलेट करना

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

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

Chrome के DevTools के ऐप्लिकेशन पैनल में एक स्टोरेज सबपैनल होता है. इससे यह जानकारी मिलती है कि पेज के मौजूदा स्टोरेज कोटा का कितना इस्तेमाल हो रहा है. इससे कस्टम कोटा को मेगाबाइट में तय करने की सुविधा भी मिलती है. लागू होने पर, Chrome कस्टम स्टोरेज कोटा लागू करेगा, ताकि उसकी जांच की जा सके.

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

आसानी से डेवलपमेंट, बेहतर प्रोडक्टिविटी

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