फिर से पुष्टि करने के दौरान पुरानी जानकारी को अपडेट करना

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

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

Cache-Control रिस्पॉन्स हेडर में max-age के साथ-साथ stale-while-revalidate सेट करने की सुविधा, Chrome 75 और Firefox 68 में उपलब्ध है.

जो ब्राउज़र stale-while-revalidate के साथ काम नहीं करते वे कॉन्फ़िगरेशन वैल्यू को अनदेखा कर देंगे और max-age का इस्तेमाल करेंगे, जैसा कि ऊपर बताया गया है...

इसका क्या मतलब है?

आइए, stale-while-revalidate को दो हिस्सों में बांटते हैं: कैश मेमोरी में सेव किया गया रिस्पॉन्स पुराना हो सकता है और दोबारा उसकी पुष्टि करने की प्रोसेस.

सबसे पहले, ब्राउज़र को कैसे पता चलता है कि कैश मेमोरी में सेव किया गया जवाब "पुराना" है या नहीं? stale-while-revalidate वाले Cache-Control रिस्पॉन्स हेडर में max-age भी होना चाहिए. max-age से तय किए गए सेकंड की संख्या से यह तय होता है कि डेटा पुराना है या नहीं. कैश मेमोरी में सेव किए गए किसी भी ऐसे रिस्पॉन्स को नया माना जाता है जो max-age से नया हो. साथ ही, कैश मेमोरी में सेव किए गए पुराने रिस्पॉन्स को पुराना माना जाता है.

अगर कैश मेमोरी में सेव किया गया जवाब अब भी अप-टू-डेट है, तो ब्राउज़र के अनुरोध को पूरा करने के लिए, उसका इस्तेमाल किया जा सकता है. stale-while-revalidate के हिसाब से, इस स्थिति में कुछ करने की ज़रूरत नहीं है.

हालांकि, अगर कैश मेमोरी में सेव किया गया रिस्पॉन्स पुराना है, तो उम्र के आधार पर एक और जांच की जाती है: क्या कैश मेमोरी में सेव किए गए रिस्पॉन्स की उम्र, stale-while-revalidate सेटिंग में दी गई अतिरिक्त समयावधि के अंदर है?

अगर किसी पुराने रिस्पॉन्स की उम्र इस विंडो में आती है, तो इसका इस्तेमाल ब्राउज़र के अनुरोध को पूरा करने के लिए किया जाएगा. साथ ही, नेटवर्क से "पुष्टि करने का अनुरोध" इस तरह किया जाएगा कि कैश मेमोरी में सेव किए गए जवाब का इस्तेमाल करने में देरी न हो. रिटर्न किए गए रिस्पॉन्स में, पहले से कैश मेमोरी में सेव किए गए रिस्पॉन्स जैसी जानकारी हो सकती है या यह जानकारी अलग हो सकती है. दोनों ही मामलों में, नेटवर्क रिस्पॉन्स को लोकल तौर पर सेव किया जाता है. साथ ही, जो पहले कैश मेमोरी थी उसकी जगह लिया जाता है. साथ ही, आने वाले समय में max-age की तुलना करने के दौरान इस्तेमाल किए जाने वाले "फ़्रेशनेस" टाइमर को रीसेट किया जाता है.

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

लाइव उदाहरण

यहां मौजूदा समय दिखाने वाले एचटीटीपी एपीआई का एक आसान उदाहरण दिया गया है. इसमें, खास तौर पर, घंटे के बाद बचे हुए मिनटों की संख्या दिख रही है.

इस स्थिति में, वेब सर्वर अपने एचटीटीपी रिस्पॉन्स में इस Cache-Control हेडर का इस्तेमाल करता है:

Cache-Control: max-age=1, stale-while-revalidate=59

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

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

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

यहां उन तीन अलग-अलग स्थितियों के बारे में बताया गया है. साथ ही, हमारे उदाहरण में, उनमें से हर स्थिति के लागू होने की समयावधि भी दी गई है:

पिछले सेक्शन में दी गई जानकारी को दिखाने वाला डायग्राम.

इस्तेमाल के सामान्य उदाहरण क्या हैं?

"घंटे के बाद के मिनट" एपीआई सेवा के लिए ऊपर दिया गया उदाहरण बनावटी है. हालांकि, इससे इस्तेमाल के उदाहरण के बारे में पता चलता है. यह ऐसी सेवाओं के बारे में बताता है जिनमें ऐसी जानकारी दी जाती है जिसे रीफ़्रेश करने की ज़रूरत होती है. हालांकि, इसमें कुछ समय तक पुरानी जानकारी का इस्तेमाल किया जा सकता है.

कम जानकारी वाले उदाहरणों में, मौसम की मौजूदा स्थिति के लिए एपीआई या पिछले एक घंटे में लिखी गई मुख्य खबरों की हेडलाइन शामिल हो सकती हैं.

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

यह सर्विस वर्कर के साथ कैसे इंटरैक्ट करता है?

अगर आपने stale-while-revalidate के बारे में सुना है, तो हो सकता है कि यह सेवा वर्कर में इस्तेमाल की गई रेसिपी के संदर्भ में हो.

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

सर्विस वर्कर तरीके का इस्तेमाल तब करें, जब...

  • आप अपने वेब ऐप्लिकेशन में सर्विस वर्कर का इस्तेमाल पहले से ही कर रहे हैं.
  • आपको अपने कैश मेमोरी में मौजूद कॉन्टेंट पर बेहतर कंट्रोल चाहिए और आपको कम से कम हाल ही में इस्तेमाल किए गए कॉन्टेंट की समयसीमा खत्म होने की नीति जैसी कोई नीति लागू करनी है. Workbox के कैश मेमोरी में डेटा सेव होने की समयसीमा वाले मॉड्यूल से, इस काम में मदद मिल सकती है.
  • आपको पुष्टि करने के दौरान, बैकग्राउंड में पुराने जवाब में बदलाव होने पर सूचना चाहिए. इस काम को करने के लिए, Workbox का ब्रॉडकास्ट कैश अपडेट मॉड्यूल आपके काम आ सकता है.
  • आपको सभी मॉडर्न ब्राउज़र में stale-while-revalidate के इस व्यवहार की ज़रूरत है.

कैश-कंट्रोल अप्रोच का इस्तेमाल तब करें, जब…

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

अगर किसी सेवा वर्कर का इस्तेमाल किया जा रहा है और आपने Cache-Control हेडर के ज़रिए कुछ रिस्पॉन्स के लिए stale-while-revalidate चालू किया है, तो आम तौर पर, सेवा वर्कर को अनुरोध का जवाब देने का "पहला मौका" मिलेगा. अगर सेवा वर्कर जवाब नहीं देता है या जवाब जनरेट करने की प्रोसेस में, fetch() का इस्तेमाल करके नेटवर्क अनुरोध करता है, तो Cache-Control हेडर के ज़रिए कॉन्फ़िगर किया गया व्यवहार लागू हो जाएगा.

ज़्यादा जानें

सैमुअल जेलर की हीरो इमेज.