यह लेख कंपनी के logo/profile image upload, जो FileStack पर निर्भर था, उसे S3 में एकीकृत करते समय आई समस्याओं और उनके समाधान की प्रक्रिया को समेटता है.
शुरुआत की पृष्ठभूमि
- शुरुआत में FileStack ने “core नहीं होने वाले upload feature” को लागू करने का समय बहुत कम कर दिया, और production में भी लंबे समय तक बिना किसी समस्या के इस्तेमाल होता रहा
- समय के साथ S3 infrastructure तैयार हो गया, लेकिन केवल logo/profile का external service पर रह जाना खटकने लगा
- Dev/टेस्ट environment में FileStack Rate Limit की वजह से images के टूटने की समस्या बार-बार होने लगी
समस्या
- लोकल में AWS S3 के साथ development करते समय STS temporary token expiry, network dependency, और onboarding hurdle असुविधाजनक थे
- migration के दौरान लगभग छूट जाने वाला एक trap: email logo presigned URL TTL expire होने के कारण बाद में टूट सकता है
समाधान
- लोकल development को MinIO से सरल बनाया गया (S3 API compatible, Docker से आसान setup)
- email logo के लिए bucket को private रखते हुए, CloudFront में केवल public/* path को public करने के तरीके से अलग किया गया
इस बार क्यों किया
- “legacy improvement” हमेशा ROI के सवाल की वजह से टल जाता है, लेकिन इस बार AI coding tools की वजह से trial-and-error की लागत कम हुई, इसलिए लगा कि “इसे आज़माया जा सकता है”
- सच कहें तो AI के बिना इसे आज़माया ही नहीं जाता
सीखी गई बातें
- FileStack कोई खराब विकल्प नहीं था; उस समय वही सबसे अच्छा विकल्प था, और “इसे कब हटाना है” यही ज्यादा महत्वपूर्ण सवाल है
- परिस्थिति बदलने पर इसे हटाया जा सकता है, और AI tools उस “बाद में” को और आसान बना रहे हैं
अभी कोई टिप्पणी नहीं है.