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

अब कई वर्षों के लिए, कैशिंग के उन्नत तरीकों पर लगभग हर लेख उत्पादन में निम्नलिखित तकनीकों का उपयोग करने की सिफारिश करता है:

• फ़ाइल के नामों को उनमें निहित डेटा के संस्करण के बारे में जानकारी (आमतौर पर फ़ाइलों में डेटा के हैश के रूप में) में जोड़ा जाता है।
• HTTP हेडर सेट करना Cache-Control: max-age और समय Expires , जो सामग्री के कैशिंग समय को नियंत्रित करता है (जो संसाधन पर लौटने वाले आगंतुकों के लिए प्रासंगिक सामग्रियों के पुन: सत्यापन को समाप्त करता है)।

परियोजनाओं के निर्माण के लिए सभी उपकरण जो मुझे पता है कि हैश फ़ाइल में जोड़ने का समर्थन उनकी सामग्री है। यह एक साधारण कॉन्फ़िगरेशन नियम (जैसे नीचे दिखाया गया है) का उपयोग करके किया जाता है:

 filename: '[name]-[contenthash].js' 

इस तकनीक के लिए इस तरह के व्यापक समर्थन ने इस तथ्य को जन्म दिया है कि यह अभ्यास बेहद आम हो गया है।

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

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

यहां समस्या यह है कि यदि यह सब संयुक्त है, तो यह शायद ही कभी दीर्घकालिक डेटा कैशिंग की दक्षता में वृद्धि की ओर जाता है।

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

फ़ाइल का नाम संस्करण जारी करना

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

अगले निर्भरता आरेख में, आप कोड आधार प्रविष्टि बिंदु देख सकते हैं - main का मूल टुकड़ा, साथ ही साथ तीन निर्भरता टुकड़े लोड किए गए asynchronously - dep1 , dep2 और dep3 । एक vendor खंड भी है जिसमें सभी साइट निर्भरताएं node_modules । कैशिंग दिशानिर्देशों के अनुसार सभी फ़ाइल नाम, इन फ़ाइलों की सामग्री के हैश शामिल हैं।


विशिष्ट जावास्क्रिप्ट मॉड्यूल निर्भरता पेड़

चूंकि vendor खंड से dep2 और dep3 आयात मॉड्यूल, तो प्रोजेक्ट dep3 द्वारा उत्पन्न उनके कोड के शीर्ष पर, हम सबसे अधिक संभावना आयात आयात पाएंगे जो कुछ इस तरह दिखते हैं:

 import {...} from '/vendor-5e6f.mjs'; 

अब आइए विचार करें कि अगर vendor टुकड़े की सामग्री बदल जाती है तो क्या होगा।

यदि ऐसा होता है, तो संबंधित फ़ाइल के नाम का हैश भी बदल जाएगा। और जब से इस फ़ाइल के नाम का लिंक dep2 और dep3 लिए आयात आदेशों में है, तब इन आयात आदेशों को बदलने के लिए यह आवश्यक होगा:

 -import {...} from '/vendor-5e6f.mjs'; +import {...} from '/vendor-d4a1.mjs'; 

हालाँकि, चूंकि ये आयात आदेश dep2 और dep3 की सामग्री का हिस्सा हैं, इसलिए उन्हें बदलने का मतलब है कि dep2 और dep3 फ़ाइलों की सामग्री का हैश भी dep3 dep2 । और इसका मतलब है कि इन फाइलों के नाम भी बदल जाएंगे।

लेकिन बात यहीं खत्म नहीं होती है। चूंकि main टुकड़ा dep2 और dep3 टुकड़े आयात करता है, और उनकी फ़ाइल नाम बदल गए हैं, इसलिए main में आयात कमांड भी बदल जाएंगे:

 -import {...} from '/dep2-3c4d.mjs'; +import {...} from '/dep2-2be5.mjs'; -import {...} from '/dep3-d4e5.mjs'; +import {...} from '/dep3-3c6f.mjs'; 

और अंत में, चूंकि main फ़ाइल की सामग्री बदल गई है, इसलिए इस फ़ाइल का नाम भी बदलना होगा।

इस प्रकार अब निर्भरता आरेख दिखेगा।


पेड़ की पत्ती के नोड्स के कोड में एक एकल परिवर्तन से प्रभावित निर्भरता के पेड़ में मॉड्यूल

यह उदाहरण दिखाता है कि कैसे सिर्फ एक फ़ाइल में किए गए एक छोटे से कोड परिवर्तन ने बंडल टुकड़ों के 80% के कैश को अमान्य कर दिया।

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

यह हमें निम्नलिखित प्रश्न की ओर ले जाता है: "क्या यह संभव है कि अपरिवर्तनीय संसाधनों और दीर्घकालिक कैशिंग का लाभ प्राप्त किया जा सके, जबकि कैश कैस्केडिंग से पीड़ित नहीं हैं?"

समस्या को हल करने के दृष्टिकोण

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

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

जैसा कि यह निकला, इस लक्ष्य को प्राप्त करने के कई तरीके हैं:

• आयात कार्ड।
• सेवा कार्यकर्ता।
• संसाधनों को लोड करने के लिए मूल स्क्रिप्ट।

इन तंत्रों पर विचार करें।

दृष्टिकोण # 1: आयात कार्ड

आयात मानचित्र कैश अमान्यकरण का सबसे सरल समाधान हैं। इसके अलावा, इस तंत्र को लागू करना सबसे आसान है। लेकिन, दुर्भाग्य से, यह केवल क्रोम में समर्थित है (यह सुविधा, इसके अलावा, स्पष्ट रूप से सक्षम होना चाहिए )।

इसके बावजूद, मैं आयात कार्ड के बारे में कहानी शुरू करना चाहता हूं, क्योंकि मुझे यकीन है कि यह निर्णय भविष्य में सबसे आम हो जाएगा। इसके अलावा, आयात कार्ड के साथ काम करने का वर्णन हमारी समस्या को हल करने के लिए अन्य तरीकों की विशेषताओं को समझाने में मदद करेगा।

कैस्केडिंग कैश अमान्य को रोकने के लिए आयात मानचित्र का उपयोग तीन चरणों में होता है।

1स्टेप १

आपको बंडलर को कॉन्फ़िगर करने की आवश्यकता है ताकि प्रोजेक्ट का निर्माण करते समय इसमें उनके नाम की फ़ाइलों की सामग्री के हैश शामिल न हों।

यदि आप किसी प्रोजेक्ट को इकट्ठा करते हैं जिसका मॉड्यूल पिछले उदाहरण से आरेख में दिखाया गया है, तो फ़ाइल नामों में उनकी सामग्री को शामिल किए बिना, प्रोजेक्ट आउटपुट डायरेक्टरी में फाइलें इस तरह दिखाई देंगी:

 dep1.mjs dep2.mjs dep3.mjs main.mjs vendor.mjs 

इसी मॉड्यूल में आयात कमांड में हैश शामिल नहीं होगा:

 import {...} from '/vendor.mjs'; 

2स्टेप २

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

 dep1-b2c3.mjs", dep1.mjs dep2-3c4d.mjs", dep2.mjs dep3-d4e5.mjs", dep3.mjs main-1a2b.mjs", main.mjs vendor-5e6f.mjs", vendor.mjs 

3स्टेप ३

आपको एक JSON ऑब्जेक्ट बनाने की ज़रूरत है जो प्रत्येक फ़ाइल के पत्राचार के बारे में जानकारी संग्रहीत करता है जिसके नाम पर प्रत्येक फ़ाइल में कोई हैश नहीं है जिसके नाम में हैश है। इस ऑब्जेक्ट को HTML टेम्प्लेट में जोड़ना होगा।

यह JSON ऑब्जेक्ट एक आयात नक्शा है। यहाँ यह है कि यह कैसा दिख सकता है:

 <script type="importmap"> {  "imports": {    "/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",  } } </script> 

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

यदि आप एक उदाहरण के रूप में इस आयात मानचित्र का उपयोग करते हैं, तो आप यह पता लगा सकते हैं कि /vendor.mjs फ़ाइल का संदर्भ देने वाला आयात आदेश वास्तव में /vendor.mjs फ़ाइल को क्वेरी और लोड करेगा:

 //    `/vendor.mjs`,  `/vendor-5e6f.mjs`. import {...} from '/vendor.mjs'; 

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

शायद आप अब सोच रहे हैं कि मैंने फ़ाइलों का नाम बदलने के बजाय प्रत्येक फ़ाइल की एक प्रतिलिपि क्यों बनाई। यह उन ब्राउज़रों का समर्थन करने के लिए आवश्यक है जो आयात नक्शे के साथ काम नहीं कर सकते। पिछले उदाहरण में, ऐसे ब्राउज़र केवल /vendor.mjs फ़ाइल देखेंगे और बस इस फ़ाइल को डाउनलोड करते हैं, जैसा कि वे आमतौर पर करते हैं, समान निर्माणों का सामना करते हैं। नतीजतन, यह पता चला है कि दोनों फाइलें सर्वर पर मौजूद होनी चाहिए।

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

जारी रखने के लिए ...

प्रिय पाठकों! क्या आप कैश अमान्यकरण के बारे में जानते हैं?