Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

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

Jeff Posnick

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

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

सर्विस वर्कर

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

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

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

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

Cache Storage API

Browser Support

Source

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 Storage API में पुराना कॉन्टेंट जुड़ सकता है. Cache Storage API का असरदार तरीके से इस्तेमाल करने के लिए, एचटीटीपी कैश मेमोरी के काम करने के तरीके को समझना ज़रूरी है.

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

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

ज़्यादा जानने के लिए, कैश मेमोरी एपीआई: बुनियादी जानकारी देखें.

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

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

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

एक छोटा सा ब्रेक: प्रॉमिस और async/await

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

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

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