आपको नेटवर्क से जुड़ने में परेशानी हो रही है. ब्राउज़र की एचटीटीपी कैश मेमोरी आपके लिए सबसे अहम है. हालांकि, जैसा कि आपको पता है, यह सिर्फ़ उन वर्शन वाले यूआरएल को लोड करते समय असरदार होता है जिन्हें आपने पहले देखा है. अपने-आप में, एचटीटीपी कैश मेमोरी काफ़ी नहीं है.
अच्छी बात यह है कि आपके लिए दो नए टूल उपलब्ध हैं: सर्विस वर्कर और कैश स्टोरेज एपीआई. क्योंकि इन दोनों का इस्तेमाल अक्सर एक साथ किया जाता है, इसलिए दोनों के बारे में एक साथ सीखना फ़ायदेमंद होता है.
सर्विस वर्कर
सर्विस वर्कर, ब्राउज़र में पहले से मौजूद होता है और कुछ अतिरिक्त JavaScript कोड से कंट्रोल होता है. इस कोड को बनाने की ज़िम्मेदारी आपकी होती है. इसे उन अन्य फ़ाइलों के साथ डिप्लॉय किया जाता है जो आपका असल वेब ऐप्लिकेशन बनाती हैं.
सर्विस वर्कर के पास कुछ खास अधिकार होते हैं. अन्य कामों के साथ-साथ, यह आपके वेब ऐप्लिकेशन से किसी आउटगोइंग अनुरोध का इंतज़ार करता है और फिर उसे इंटरसेप्ट करके कार्रवाई करता है. सर्विस वर्कर, रोके गए इस अनुरोध के साथ क्या करता है, यह आप पर निर्भर करता है.
कुछ अनुरोधों के लिए, कार्रवाई का सबसे अच्छा तरीका यह हो सकता है कि अनुरोध को नेटवर्क पर जारी रखने की अनुमति दी जाए. यह ठीक वैसा ही है जैसे अगर कोई सर्विस वर्कर ना होता, तो क्या होता.
हालांकि, दूसरे अनुरोधों के लिए, ब्राउज़र की एचटीटीपी कैश मेमोरी से ज़्यादा लचीली सुविधा का फ़ायदा लिया जा सकता है. साथ ही, नेटवर्क की चिंता किए बिना, भरोसेमंद तेज़ी से रिस्पॉन्स दिया जा सकता है. इसमें पहेली के दूसरे हिस्से का इस्तेमाल करने के लिए कहा जाता है: कैश स्टोरेज एपीआई.
कैश मेमोरी एपीआई
कैश मेमोरी एपीआई, डेवलपर को कैश मेमोरी के कॉन्टेंट पर पूरा कंट्रोल देकर, संभावनाओं की एक नई रेंज खोलता है. एचटीटीपी हेडर और ब्राउज़र की पहले से मौजूद heuristics के कॉम्बिनेशन के बजाय, कैश मेमोरी एपीआई, कैश मेमोरी में कोड पर आधारित तरीका दिखाता है. कैश मेमोरी एपीआई खास तौर पर तब काम आता है, जब उसे आपके सर्विस वर्कर के JavaScript से कॉल किया जाता है.
इंतज़ार करें... क्या अभी कोई और कैश मेमोरी में सेव किया गया है?
आप खुद से ऐसे सवाल पूछ रहे होंगे कि "क्या मुझे अब भी अपने एचटीटीपी हेडर कॉन्फ़िगर करने होंगे?" और "मैं इस नए कैश की मदद से ऐसा क्या करूं जो एचटीटीपी कैश के साथ नहीं हो पाता था?" चिंता न करें—ये स्वाभाविक प्रतिक्रियाएं हैं.
हमारा सुझाव है कि आप अपने वेब सर्वर पर Cache-Control हेडर कॉन्फ़िगर करें. ऐसा तब भी करें, जब आपको पता हो कि कैश स्टोरेज एपीआई का इस्तेमाल किया जा रहा है. आम तौर पर, बिना वर्शन वाले यूआरएल के लिए Cache-Control: no-cache और/या हैश जैसे वर्शन की जानकारी वाले यूआरएल के लिए Cache-Control: max-age=31536000 सेट करके, समस्या को हल किया जा सकता है.
कैश मेमोरी एपीआई की कैश मेमोरी में डेटा भरते समय, ब्राउज़र, एचटीटीपी कैश में डिफ़ॉल्ट एंट्री की जांच करता है और अगर वे मिलते हैं, तो उनका इस्तेमाल करता है. अगर कैश मेमोरी एपीआई कैश में, वर्शन वाले यूआरएल जोड़े जा रहे हैं, तो ब्राउज़र एक और नेटवर्क अनुरोध करने से बचता है. इसका दूसरा पहलू यह है कि अगर गलत तरीके से कॉन्फ़िगर किए गए Cache-Control हेडर का इस्तेमाल किया जा रहा है (जैसे, वर्शन न बदले गए यूआरएल के लिए, लंबे समय तक कैश मेमोरी में सेव रहने का समय तय करना), तो उस पुराने कॉन्टेंट को कैश मेमोरी एपीआई में जोड़कर, चीज़ों को और खराब बनाया जा सकता है. कैश मेमोरी एपीआई का असरदार तरीके से इस्तेमाल करने के लिए, अपनी एचटीटीपी कैश मेमोरी के काम को क्रम से लगाना एक ज़रूरी शर्त है.
जहां तक इस नए एपीआई के साथ अब संभव है, वहां इसके लिए कई चीज़ें हैं. ऐसे कुछ सामान्य इस्तेमाल जो सिर्फ़ एचटीटीपी कैश के साथ मुश्किल या नामुमकिन हो सकते हैं, उनमें ये शामिल हैं:
- कैश मेमोरी में सेव किए गए कॉन्टेंट के लिए, "बैकग्राउंड में रीफ़्रेश करें" तरीके का इस्तेमाल करें. इस तरीके को 'हाल ही में अपडेट किए जाने के दौरान पुष्टि' कहते हैं.
- कैश मेमोरी में सेव किए जाने वाले एसेट की ज़्यादा से ज़्यादा संख्या की सीमा लागू करें. साथ ही, सीमा पूरी होने पर आइटम हटाने के लिए पसंद के मुताबिक समयसीमा खत्म होने की नीति लागू करें.
- पहले से कैश मेमोरी में सेव किए गए और नए नेटवर्क रिस्पॉन्स की तुलना करके, देखें कि क्या डेटा में कोई बदलाव हुआ है. साथ ही, उपयोगकर्ता को बटन का इस्तेमाल करके कॉन्टेंट अपडेट करने की सुविधा दें, ताकि वे यह देख सकें कि डेटा कब अपडेट हुआ है.
ज़्यादा जानने के लिए, कैश एपीआई: एक क्विक गाइड देखें.
एपीआई नट और बोल्ट
एपीआई के डिज़ाइन से जुड़ी कुछ बातों का ध्यान रखना ज़रूरी है:
Requestऑब्जेक्ट का इस्तेमाल, इन कैश मेमोरी में सेव किए गए डेटा को पढ़ते और उसमें बदलाव करते समय, यूनीक की के तौर पर किया जाता है. सुविधा के तौर पर, आपके पास असलRequestऑब्जेक्ट के बजाय,'https://example.com/index.html'जैसी यूआरएल स्ट्रिंग को कुंजी के तौर पर पास करने का विकल्प है. एपीआई इसे अपने-आप मैनेज कर देगा.Responseऑब्जेक्ट का इस्तेमाल, इन कैश मेमोरी में वैल्यू के तौर पर किया जाता है.- डेटा को कैश मेमोरी में सेव करते समय, दिए गए
ResponseकेCache-Controlहेडर को असरदार तरीके से अनदेखा किया जाता है. इसमें अपने-आप, खत्म होने की या अपडेट होने की कोई जांच नहीं होती है. कैश मेमोरी में किसी आइटम को सेव करने के बाद, वह तब तक बना रहेगा, जब तक आपका कोड उसे पूरी तरह से हटा नहीं देता. (आपकी ओर से कैश रखरखाव को आसान बनाने के लिए लाइब्रेरी हैं. इन विषयों के बारे में इस सीरीज़ में आगे बताया जाएगा.) - पुराने सिंक्रोनस एपीआई, जैसे कि
LocalStorageके उलट, कैश मेमोरी वाले एपीआई की सभी कार्रवाइयां एसिंक्रोनस होती हैं.
एक छोटा रास्ता: प्रॉमिस और इंतज़ार करना
सर्विस वर्कर और कैश स्टोरेज एपीआई,
एसिंक्रोनस प्रोग्रामिंग कॉन्सेप्ट का इस्तेमाल करते हैं.
खास तौर पर, वे एक साथ काम नहीं करने वाली कार्रवाइयों के आने वाले नतीजे दिखाने के वादों
पर काफ़ी भरोसा करते हैं. शुरू करने से पहले, आपको वादाओं और उनसे जुड़े async/await के सिंटैक्स के बारे में अच्छे से जान लेना चाहिए.
उस कोड को अभी डिप्लॉय न करें
ये तरीके अहम हैं और इन्हें इसी तरह इस्तेमाल किया जा सकता है, लेकिन कैश मेमोरी एपीआई और सर्विस वर्कर, दोनों ही कम लेवल के बिल्डिंग ब्लॉक होते हैं. इनमें कई एज केस और "gotchas" भी मौजूद हैं. कुछ ऐसे उच्च-स्तरीय टूल हैं जो उन API की मुश्किल चीज़ों को आसान बनाने में मदद कर सकते हैं और प्रोडक्शन के लिए तैयार सर्विस वर्कर बनाने के लिए ज़रूरी सभी सुविधाएं उपलब्ध कराते हैं. अगली गाइड में, इस तरह के एक टूल के बारे में बताया गया है: वर्कबॉक्स.