ஒரு Cached React Bundle எவ்வாறு தவறான Database-க்கு தரவை அனுப்பியது

நாங்கள் ஒரு காலக்கெடுவை (deadline) நெருங்கிக் கொண்டிருந்தோம். Backend குழு ஒரு புதிய API மற்றும் புதிய database-க்கு மாற்றியது (migrated). Frontend குழு AWS Amplify-இல் உள்ள environment variables-களைப் புதுப்பித்து, குறியீட்டை (code) பதிவேற்றியது (pushed).

Deployment வெற்றிகரமாக முடிந்தது. நாங்கள் எங்கள் மடிக்கணினிகளை மூடினோம். வேலை முடிந்துவிட்டது என்று நினைத்தோம்.

நாங்கள் தவறாக நினைத்தோம்.

ஒரு பொறியாளர் பழைய API server-இன் logs-களைச் சரிபார்த்தார். அந்த server இயங்காமல் இருக்க வேண்டும் என்று கருதப்பட்டது. ஆனால் அது இயங்கிக் கொண்டிருந்தது. அது உண்மையான client கோரிக்கைகளைப் (requests) பெற்று, பழைய database-இல் தரவை எழுதிக் கொண்டிருந்தது.

இரண்டு மணிநேரத்திற்கு, உண்மையான client தரவு தவறான இடத்திற்குச் சென்றது.

இது ஏன் நடந்தது மற்றும் நாங்கள் இதை எவ்வாறு சரிசெய்தோம் என்பது இதோ.

The Problem

AWS Amplify போன்ற CDNs-இல் இயங்கும் React apps, build time-இல் environment variables-களை மாற்றியமைக்கும். நீங்கள் ஒரு build-ஐ இயக்கும்போது, bundler ஒவ்வொரு variable-ஐயும் கண்டறிந்து, அதை ஒரு hardcoded string-ஆக மாற்றும்.

API URL நேரடியாக JavaScript file-இல் இணைக்கப்பட்டிருந்தது (embedded).

நாங்கள் deploy செய்தபோது, புதிய பயனர்களுக்குப் புதிய bundle கிடைத்தது. ஆனால் ஏற்கனவே app-ஐத் திறந்து வைத்திருந்த பயனர்கள் அதை refresh செய்யவில்லை. அவர்கள் பழைய URL உள்ள பழைய bundle-ஐயே தொடர்ந்து பயன்படுத்திக் கொண்டிருந்தார்கள்.

பழைய server இன்னும் இயங்கிக் கொண்டிருந்ததால், இந்த clients-களுக்கு 200 OK status கிடைத்தது. அனைத்தும் சரியாகத் தெரிந்தது. ஆனால் அந்தத் தோல்வி அமைதியாக (silent) நடந்தது. அமைதியான தோல்விகளே மிகவும் ஆபத்தான வகை bugs ஆகும்.

The Three-Layer Fix

இது மீண்டும் நடக்காமல் இருப்பதை உறுதி செய்ய நாங்கள் மூன்று அடுக்குகளை உருவாக்கினோம்.

1. Runtime Configuration நாங்கள் JavaScript bundle-க்குள் URLs-களை இணைப்பதைத் தவிர்த்தோம். அதற்குப் பதிலாக, public folder-இல் ஒரு config.json file-ஐப் பயன்படுத்துகிறோம். Bundler இந்த file-ஐத் தொடாது. App render ஆவதற்கு முன்பு runtime-இல் இந்த file-ஐப் பெறுகிறது (fetches). இது புதிய sessions எப்போதும் சரியான URL-ஐப் பெறுவதை உறுதி செய்கிறது.

2. WebSocket Notifications ஒரு runtime config, ஏற்கனவே tab திறந்து வைத்திருக்கும் பயனர்களுக்கு உதவாது. எனவே, எங்கள் deployment செயல்முறையை WebSocket server-உடன் இணைத்தோம். Amplify ஒரு build-ஐ முடித்தவுடன், அது எங்கள் API-இல் உள்ள ஒரு webhook-ஐ அழைக்கும். பின்னர் server, இணைக்கப்பட்டுள்ள அனைத்து clients-களுக்கும் ஒரு செய்தியை (message) அனுப்பும். ஒரு பயனர் பழைய version-இல் இருந்தால், refresh செய்யுமாறு கேட்கும் ஒரு banner தோன்றும்.

3. Cache Management நாங்கள் எங்கள் CloudFront settings-களைப் புதுப்பித்தோம். index.html மற்றும் config.json போன்ற entry points இப்போது no-cache என அமைக்கப்பட்டுள்ளன. இது பயனர்கள் CDN edge node-லிருந்து பழைய (stale) கோப்புகளைப் பெறுவதற்குப் பதிலாக, எப்போதும் சமீபத்திய கோப்புகளைப் பெறுவதை உறுதி செய்கிறது.

The Lessons

• வரிசைப்படுத்தல்களுக்கு (deployments) இடையே மாறும் மதிப்புகளைக் கையாளும் போது, Build-time config ஒரு பொறியாகும். • சத்தத்தை விட அமைதி மிகவும் ஆபத்தானது. பழைய அமைப்புகள் 410 Gone நிலையைப் பயன்படுத்தித் தெளிவாகத் தோல்வியடைவதை உறுதி செய்யுங்கள். • காலக்கெடு அழுத்தம் கைமுறைப் படிகளைச் சிதைத்துவிடும். உங்கள் பயன்பாட்டு நீக்கச் செயல்முறையை (decommissioning process) தானியக்கமாக்குங்கள். • நீங்கள் செயல்பாட்டிற்கு கொண்டு வரும் விஷயங்களை மட்டும் கண்காணிக்காமல், நீங்கள் நிறுத்தி வைக்கும் விஷயங்களையும் கண்காணிக்கவும்.

வரிசைப்படுத்துதல் (Deployment) என்பது வெறும் குறியீட்டை (code) மட்டும் பதிவேற்றுவது அல்ல. ஒவ்வொரு வாடிக்கையாளரும் சரியான குறியீட்டைப் பயன்படுத்துவதை உறுதி செய்வதே ஆகும்.

ஆதாரம்: https://dev.to/sugan_dev/how-a-cached-react-bundle-sent-production-data-to-the-wrong-database-55n9