एक कैश्ड React Bundle ने गलत डेटाबेस में डेटा कैसे भेजा
हमने एक डेडलाइन पूरी की। बैकएंड टीम एक नए API और नए डेटाबेस पर माइग्रेट हो गई। फ्रंटएंड टीम ने AWS Amplify में एनवायरनमेंट वेरिएबल्स (environment variables) अपडेट किए और कोड पुश कर दिया।
डिप्लॉयमेंट सफल रहा। हमने अपने लैपटॉप बंद कर दिए। हमें लगा कि काम पूरा हो गया है।
हम गलत थे।
एक इंजीनियर ने पुराने API सर्वर के लॉग्स चेक किए। इस सर्वर को बंद हो जाना चाहिए था। लेकिन ऐसा नहीं हुआ। यह असली क्लाइंट रिक्वेस्ट प्राप्त कर रहा था और पुराने डेटाबेस में डेटा लिख रहा था।
दो घंटों तक, असली क्लाइंट डेटा गलत जगह जाता रहा।
यहाँ बताया गया है कि ऐसा क्यों हुआ और हमने इसे कैसे ठीक किया।
समस्या
AWS Amplify जैसे CDNs पर React ऐप्स बिल्ड टाइम (build time) पर एनवायरनमेंट वेरिएबल्स को रिप्लेस कर देते हैं। जब आप बिल्ड चलाते हैं, तो बंडलर (bundler) हर वेरिएबल को ढूंढता है और उसे एक हार्डकोडेड स्ट्रिंग (hardcoded string) से बदल देता है।
API URL भौतिक रूप से JavaScript फ़ाइल में एम्बेडेड (embedded) था।
जब हमने डिप्लॉय किया, तो नए उपयोगकर्ताओं को नया बंडल मिला। लेकिन ऐप खोलकर बैठे मौजूदा उपयोगकर्ताओं ने कभी रिफ्रेश नहीं किया। वे पुराने बंडल को ही चलाते रहे जिसके अंदर पुराना URL हार्डकोडेड था।
चूंकि पुराना सर्वर अभी भी चल रहा था, इन क्लाइंट्स को 200 OK स्टेटस मिला। सब कुछ ठीक लग रहा था। यह विफलता 'साइलेंट' (silent) थी। साइलेंट बग सबसे खतरनाक प्रकार के बग होते हैं।
तीन-स्तरीय समाधान
हमने यह सुनिश्चित करने के लिए तीन लेयर्स बनाईं कि ऐसा दोबारा कभी न हो।
1. रनटाइम कॉन्फ़िगरेशन हमने JavaScript बंडल में URL को 'बेक' (bake) करना बंद कर दिया। इसके बजाय, हम public फोल्डर में एक config.json फ़ाइल का उपयोग करते हैं। बंडलर इस फ़ाइल को नहीं छूता है। ऐप रेंडर होने से पहले रनटाइम पर इस फ़ाइल को फेच (fetch) करता है। यह सुनिश्चित करता है कि नए सेशन्स को हमेशा सही URL मिले।
2. WebSocket नोटिफिकेशन रनटाइम कॉन्फ़िगरेशन उन उपयोगकर्ताओं की मदद नहीं करता जिनका टैब खुला हुआ है। हमने अपनी डिप्लॉयमेंट प्रक्रिया को अपने WebSocket सर्वर से जोड़ दिया। जब Amplify बिल्ड पूरा कर लेता है, तो यह हमारे API पर एक वेबहुक (webhook) कॉल करता है। सर्वर फिर सभी कनेक्टेड क्लाइंट्स को एक मैसेज भेजता है। यदि कोई उपयोगकर्ता पुराने वर्ज़न पर है, तो एक बैनर दिखाई देता है जो उन्हें रिफ्रेश करने के लिए कहता है।
3. कैश मैनेजमेंट हमने अपनी CloudFront सेटिंग्स को अपडेट किया। index.html और config.json जैसे एंट्री पॉइंट्स को अब no-cache पर सेट कर दिया गया है। यह सुनिश्चित करता है कि उपयोगकर्ता CDN एज नोड (edge node) से पुराने वर्ज़न के बजाय हमेशा नवीनतम फ़ाइलें ही प्राप्त करें।
सीख
• बिल्ड-टाइम कॉन्फ़िगरेशन उन वैल्यूज़ के लिए एक जाल है जो डिप्लॉयमेंट के बीच बदलती रहती हैं। • शोर (noise) की तुलना में चुप्पी अधिक खतरनाक होती है। पुराने सिस्टम को 410 Gone स्टेटस के साथ स्पष्ट रूप से विफल (fail) होने दें। • डेडलाइन का दबाव मैन्युअल स्टेप्स को बिगाड़ देता है। अपनी डीकमीशनिंग प्रक्रिया को ऑटोमेट करें। • केवल उन चीज़ों की निगरानी न करें जिन्हें आप चालू कर रहे हैं, बल्कि उन चीज़ों की भी निगरानी करें जिन्हें आप बंद कर रहे हैं।
डिप्लॉयमेंट का मतलब केवल कोड पुश करना नहीं है। इसका मतलब यह सुनिश्चित करना है कि हर क्लाइंट अंततः सही कोड चला रहा हो।
स्रोत: https://dev.to/sugan_dev/how-a-cached-react-bundle-sent-production-data-to-the-wrong-database-55n9