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

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

Jeff Posnick

क्या शिप किया गया है?

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 को दो हिस्सों में बांटते हैं: यह आइडिया कि कैश मेमोरी में सेव किया गया जवाब पुराना हो सकता है और दोबारा पुष्टि करने की प्रक्रिया.

सबसे पहले, ब्राउज़र को कैसे पता चलता है कि कैश मेमोरी में सेव किया गया रिस्पॉन्स "पुरानी" है या नहीं? Cache-Control रिस्पॉन्स हेडर, जिसमें stale-while-revalidate होता है, में 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

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

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

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

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

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

आम तौर पर, किन मामलों में इसका इस्तेमाल किया जाता है?

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

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

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

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

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

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

सर्विस वर्कर अप्रोच का इस्तेमाल तब करें, जब...

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

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

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

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

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

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