कैस्केडिंग कैश अमान्य। भाग २

कैस्केडिंग कैश अमान्यकरण के लिए समर्पित सामग्री के अनुवाद के पहले भाग में , हमने समस्या की प्रकृति पर चर्चा की और इसके समाधान में से एक पर विचार किया, जिसमें आयात कार्ड का उपयोग करना शामिल है। इसके प्लस कार्यान्वयन में आसानी है। और माइनस - खराब ब्राउज़र समर्थन। आज हम इस समस्या को हल करने के अन्य तरीकों के बारे में बात करेंगे।

दृष्टिकोण # 2: सेवा कर्मी

समस्या का दूसरा समाधान एक सेवा कार्यकर्ता का उपयोग करके आयात कार्ड की कार्यक्षमता को पुन: पेश करना है।

उदाहरण के लिए, सेवा कार्यकर्ता का उपयोग करके, आप उन घटनाओं को fetch कर सकते हैं, जिनका उद्देश्य आयात कार्ड की चाबियों के अनुरूप पते पर स्थित सामग्री को लोड करना है। इन अनुरोधों को क्रियान्वित करके, आप उन फ़ाइलों को अपलोड कर सकते हैं जिनके नाम में उनकी सामग्री के हैश शामिल हैं:

 const importMap = {  '/main.mjs': '/main-1a2b.mjs',  '/dep1.mjs': '/dep1-b2c3.mjs',  '/dep2.mjs': '/dep2-3c4d.mjs',  '/dep3.mjs': '/dep3-d4e5.mjs',  '/vendor.mjs': '/vendor-5e6f.mjs', }; addEventListener('fetch', (event) => {  const oldPath = new URL(event.request.url, location).pathname;  if (importMap.hasOwnProperty(oldPath)) {    const newPath = importMap[oldPath];    event.respondWith(fetch(new Request(newPath, event.request)));  } }); 

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

यदि आप इसे ध्यान में रखते हैं, तो ऐसा लग सकता है कि सेवा कार्यकर्ता कैश अमान्यकरण की समस्या का उचित समाधान नहीं है।

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

यह है कि कैसे वर्कबॉक्स जैसे उपकरण प्री-कैश संसाधन काम करते हैं। वे विधानसभा से प्रत्येक फ़ाइल की सामग्री की हैश उत्पन्न करते हैं और सेवा कार्यकर्ता में फ़ाइल नामों के पत्राचार को संग्रहीत करते हैं (यह बाहरी आयात कार्ड की तरह कुछ निकलता है)। इसके अलावा, वे एक सेवा कार्यकर्ता की पहली स्थापना के दौरान संसाधनों को कैश करते हैं और उन ईवेंट श्रोताओं को जोड़ते हैं जो कैश्ड फ़ाइलों को उन अनुरोधों के जवाब में वापस करते हैं जिनके पते आयात मानचित्र में उन लोगों से मेल खाते हैं।

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

परिणामस्वरूप, जब तक आप सेवा कार्यकर्ता को अपडेट किए बिना मॉड्यूल के नए संस्करणों को तैनात करना शुरू नहीं करते हैं (और यह निश्चित रूप से अनुशंसित नहीं है), तो आप कभी भी संघर्ष या संस्करण बेमेल का सामना नहीं करेंगे।

वर्कबॉक्स-लायब्रेरी का उपयोग करके फ़ाइलों के प्रारंभिक कैशिंग को व्यवस्थित करने के लिए , आप इन फाइलों की वर्जन जानकारी के साथ फाइल एड्रेस और स्ट्रिंग्स पास कर सकते हैं precacheAndRoute() लाइब्रेरी मेथड:

 import {preacacheAndRoute} from 'workbox-precaching'; precacheAndRoute([  {url: '/main.mjs', revision: '1a2b'},  {url: '/dep1.mjs', revision: 'b2c3'},  {url: '/dep2.mjs', revision: '3c4d'},  {url: '/dep3.mjs', revision: 'd4e5'},  {url: '/vendor.mjs', revision: '5e6f'}, ]); 

कैसे संस्करणों के साथ लाइनों को उत्पन्न करने के लिए खुद डेवलपर तक है। लेकिन अगर वह उन्हें खुद बनाना नहीं चाहता है, तो प्री-कैश मेनिफेस्ट बनाने का काम वर्कबॉक्स-बिल्ड , वर्कबॉक्स-क्लाई और वर्कबॉक्स-वेबपैक-प्लगइन पैकेज को सरल बनाने में मदद करेगा (वे सभी सर्विस वर्कर कोड भी उत्पन्न कर सकते हैं)।

मेरे डेमो प्रोजेक्ट में रोलअप एप्लिकेशन ( workbox-cli का उपयोग करके) और एक वेबपैक एप्लिकेशन ( workbox-webpack-plugin का उपयोग करके) में सेवा कार्यकर्ता का उपयोग करके प्री-कैशिंग लागू करने का एक उदाहरण है।

# 3 दृष्टिकोण: संसाधनों को लोड करने के लिए कस्टम स्क्रिप्ट

यदि आपकी साइट में आयात कार्ड या सेवा श्रमिकों का उपयोग करने की क्षमता नहीं है, तो समस्या को हल करने के लिए यहां तीसरा तरीका है। इसमें लोडिंग संसाधनों के लिए अपनी स्क्रिप्ट का उपयोग करके आयात मानचित्र की कार्यक्षमता को लागू करना शामिल है।

यदि आप AMD- स्टाइल मॉड्यूल लोडर (जैसे SystemJS या आवश्यकताएँ ) से परिचित हैं , तो आप यह भी जान सकते हैं कि ये मॉड्यूल लोडर आमतौर पर मॉड्यूल उपनाम का समर्थन करते हैं। वास्तव में, SystemJS आयात नक्शे के सिंटैक्स का उपयोग करके अलियासिंग का समर्थन करता है । नतीजतन, हमारी समस्या आसानी से इस तरह से हल हो जाती है कि यह समाधान भविष्य-उन्मुख होगा (और, इसके अलावा, सभी मौजूदा ब्राउज़रों में काम करेगा)।

यदि आप रोलअप का उपयोग करते हैं, तो आप आउटपुट.फॉर्मेट विकल्प को system सेट कर सकते हैं। इस मामले में, आवेदन के लिए एक आयात मानचित्र बनाना उसी तरह से निष्पादित किया जाएगा जैसा कि कैश कैस्केडिंग की समस्या को हल करने के लिए पहले दृष्टिकोण के विवरण में वर्णित किया गया था।

मेरे डेमो एप्लिकेशन में एक उदाहरण साइट है जहां रोलअप का उपयोग सिस्टमजेएस के लिए उपयुक्त प्रारूप में सामग्री के निर्माण के लिए किया जाता है, और एक आयात नक्शा बनाने के लिए जिसके साथ फ़ाइलों के हैशेड संस्करणों को डाउनलोड करना है।

स्क्रिप्ट का उपयोग करते हुए संसाधनों को लोड करना और लोड करना

वेबपैक आपको अपनी स्क्रिप्ट का उपयोग करके संसाधनों को लोड करने में मदद करने में सक्षम है, लेकिन क्लासिक एएमडी लोडर के विपरीत, वेबपैक द्वारा उत्पन्न लोडर प्रत्येक विशिष्ट बंडल के लिए अद्वितीय है।

इस दृष्टिकोण का लाभ यह है कि वेबपैक रनटाइम (और इसलिए यह वास्तव में काम करता है) में टुकड़ों के नाम / पहचानकर्ताओं और उनके पते के बीच अपने स्वयं के मानचित्रण शामिल हो सकते हैं (यह मेरे द्वारा यहां सुझाए गए के समान है)। इसका मतलब यह है कि कोड बंटवारे का उपयोग करने वाले वेबपैक बंडल कैस्केडिंग कैश अमान्य होने की संभावना कम है।

दरअसल, वेबपैक उपयोगकर्ताओं के लिए अच्छी खबर यह है कि अगर वे वेबपैक का उपयोग करके प्रोजेक्ट असेंबली को सही तरीके से कॉन्फ़िगर करते हैं (कोड को टुकड़ों में विभाजित करते हैं, जैसा कि वेबपैक कैशिंग गाइड में वर्णित है), तो एक अलग मॉड्यूल के कोड में परिवर्तन से अमान्यता नहीं होनी चाहिए दो से अधिक टुकड़े (एक वह है जिसमें संशोधित मॉड्यूल शामिल है, दूसरा वह है जिसमें रनटाइम शामिल है)।

लेकिन मेरे पास उन लोगों के लिए कुछ बुरी खबर है जो परियोजनाओं के निर्माण के लिए वेबपैक का उपयोग करते हैं। तथ्य यह है कि इस बंडल की आंतरिक मानचित्रण प्रणाली गैर-मानक है। इसका मतलब है कि इसे मौजूदा उपकरणों के साथ एकीकृत नहीं किया जा सकता है, और उपयोगकर्ता इसे कॉन्फ़िगर नहीं कर सकता है। उदाहरण के लिए, आप स्वतंत्र रूप से आउटपुट फ़ाइलों को उत्पन्न नहीं कर सकते हैं (अर्थात, समस्या को हल करने के लिए पहले दृष्टिकोण के बारे में कहानी में वर्णित है) और मैपिंग में अपना स्वयं का हैश डाल दें। और यह वेबपैक का एक माइनस है, क्योंकि इस बंडलर द्वारा उपयोग किए गए हैश आउटपुट फ़ाइलों की सामग्री पर आधारित नहीं हैं, लेकिन स्रोत फ़ाइलों की सामग्री और बिल्ड कॉन्फ़िगरेशन पर। और इससे छोटी और सूक्ष्म त्रुटियां हो सकती हैं (उदाहरण के लिए - यहां , यहां और यहां - ऐसी त्रुटियों के बारे में संदेश)।

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

अन्य वेब परियोजना संसाधन

इससे पहले, मैंने इस बारे में बात की कि प्रोग्राम कोड वाले "हैशेड" फ़ाइल नामों के साथ जावास्क्रिप्ट कार्यक्रमों में काम करने से कैश अमान्यकरण कैसे हो सकता है। लेकिन यह समस्या अन्य वेब प्रोजेक्ट सामग्री पर लागू होती है।

तो, सीएसएस और एसवीजी फाइलें अक्सर अन्य संसाधनों (उदाहरण के लिए चित्र) का उल्लेख करती हैं, जिनके नाम में हैश के रूप में संबंधित फाइलों के संस्करणों के बारे में जानकारी हो सकती है। जेएस फ़ाइलों के मामले में, समान संसाधनों के नाम में परिवर्तन के कारण कैश कैश अमान्य होने की समस्या को हल करने के लिए, आप आयात कार्ड या सेवा श्रमिकों का उपयोग कर सकते हैं।

छवियों और वीडियो फ़ाइलों जैसे संसाधनों के लिए, यह कोई समस्या नहीं है। सभी मौजूदा सिफारिशें यहां लागू हैं।

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

परिणाम

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

यदि हम इस बारे में बात करते हैं कि क्या चुनना बेहतर है, तो, स्पष्ट रूप से, यह बहुत कुछ पर निर्भर करता है।

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

यदि आप पहले से ही सेवा कर्मचारियों का उपयोग करते हैं, खासकर यदि आप वर्कबॉक्स का उपयोग करते हैं, तो मैं यहां चर्चा की गई समस्या को हल करने के लिए दृष्टिकोण के दूसरे की सिफारिश करूंगा। जिस साइट पर इस सामग्री का मूल प्रकाशित किया जाता है, उस पर संसाधनों के प्रारंभिक कैशिंग का कार्य इस तरह से हल किया गया था।

इसके अलावा, सेवा कर्मचारी उन लोगों के लिए एकमात्र विकल्प हैं जो उत्पादन में जावास्क्रिप्ट मॉड्यूल का उपयोग करते हैं। (और यह देखते हुए कि मेरे 98% उपयोगकर्ताओं के पास ब्राउज़र हैं जो सेवा कर्मचारियों और जेएस मॉड्यूल दोनों का समर्थन करते हैं, मेरे लिए यह विकल्प चुनना मुश्किल नहीं था)।

यदि सेवा कर्मचारी आपके लिए उपयुक्त नहीं हैं, तो मैं यहां चर्चा किए गए दृष्टिकोणों में से तीसरे की सिफारिश करूंगा, जिसमें सिस्टमजेएस का उपयोग शामिल है। यह दृष्टिकोण दूसरों से बेहतर है, बूटलोडर स्क्रिप्ट के आधार पर, भविष्य पर केंद्रित है। इससे ऐसे समय में आयात कार्ड पर स्विच करना आसान होगा जब उनका समर्थन सभी ब्राउज़रों में दिखाई देगा।

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

दूसरी ओर, यदि आप अक्सर छोटे प्रोजेक्ट परिवर्तनों को तैनात करते हैं, तो आपके रिटर्निंग उपयोगकर्ता बड़ी मात्रा में कोड लोड करने की समस्या में चल सकते हैं जो पहले से ही उनके कैश में मौजूद हैं। इस समस्या को हल करने का मतलब ऐसे उपयोगकर्ताओं के लिए पृष्ठ लोडिंग प्रदर्शन में उल्लेखनीय वृद्धि होगी।

प्रिय पाठकों! कैस्केडिंग अमान्य होने से आपकी परियोजना प्रभावित होती है? यदि हां, तो कृपया हमें बताएं कि आप इसे कैसे हल करते हैं।