सर्विस वर्कर और कैश मेमोरी एपीआई

Jeff Posnick

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

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

सर्विस वर्कर

सेवा वर्कर, ब्राउज़र में पहले से मौजूद होता है. इसे कुछ अतिरिक्त JavaScript कोड से कंट्रोल किया जाता है. इस कोड को बनाने की ज़िम्मेदारी आपकी होती है. इसे उन अन्य फ़ाइलों के साथ डिप्लॉय किया जाता है जिनसे आपका असल वेब ऐप्लिकेशन बनता है.

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

कुछ अनुरोधों के लिए, सबसे सही तरीका यह हो सकता है कि अनुरोध को नेटवर्क पर भेजने की अनुमति दी जाए. ठीक वैसे ही जैसे कोई सेवा वर्कर न होने पर होता है.

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

Cache Storage API

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

रुकिए… क्या अब एक और कैश मेमोरी के बारे में सोचना है?

शायद आपके मन में ये सवाल आ रहे हों: "क्या अब भी मुझे अपने एचटीटीपी हेडर कॉन्फ़िगर करने होंगे?" और "इस नए कैश मेमोरी से क्या किया जा सकता है जो एचटीटीपी कैश मेमोरी से नहीं किया जा सकता?" चिंता न करें—ये सामान्य प्रतिक्रियाएं हैं.

हमारा सुझाव है कि आप अपने वेब सर्वर पर Cache-Control हेडर कॉन्फ़िगर करें. भले ही, आपको पता हो कि Cache Storage API का इस्तेमाल किया जा रहा है. आम तौर पर, बिना वर्शन वाले यूआरएल के लिए Cache-Control: no-cache और/या हैश जैसी वर्शन की जानकारी वाले यूआरएल के लिए Cache-Control: max-age=31536000 सेट किया जा सकता है.

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

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

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

ज़्यादा जानने के लिए, Cache API: एक छोटी गाइड देखें.

एपीआई के बारे में ज़रूरी जानकारी

एपीआई के डिज़ाइन के बारे में कुछ बातें ध्यान में रखें:

• Request इन कैश मेमोरी को पढ़ने और उनमें डेटा सेव करने के लिए, ऑब्जेक्ट का इस्तेमाल यूनीक कुंजियों के तौर पर किया जाता है. आसानी के लिए, किसी असल Request ऑब्जेक्ट के बजाय, 'https://example.com/index.html' जैसी यूआरएल स्ट्रिंग को पास किया जा सकता है. एपीआई, इसे आपके लिए अपने-आप मैनेज करेगा.
• Response इन कैश मेमोरी में, ऑब्जेक्ट का इस्तेमाल वैल्यू के तौर पर किया जाता है.
• डेटा को कैश मेमोरी में सेव करते समय, किसी Response पर मौजूद Cache-Control हेडर को अनदेखा कर दिया जाता है. इसमें, डेटा की समयसीमा खत्म होने या डेटा के अपडेट होने की जांच अपने-आप नहीं होती. साथ ही, कैश मेमोरी में किसी आइटम को सेव करने के बाद, वह तब तक बना रहेगा, जब तक आपका कोड उसे साफ़ तौर पर नहीं हटा देता. (आपके लिए कैश मेमोरी को मैनेज करना आसान बनाने के लिए, लाइब्रेरी उपलब्ध हैं. इनके बारे में इस सीरीज़ में आगे बताया जाएगा.)
• LocalStorage जैसे पुराने, सिंक्रोनस एपीआई के मुकाबले, Cache Storage API के सभी ऑपरेशन असिंक्रोनस होते हैं.

थोड़ी देर के लिए दूसरी बात: प्रॉमिस और async/await

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

उस कोड को अभी डिप्लॉय न करें

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