Express APIs के साथ मेरे द्वारा की गई 5 प्रोडक्शन गलतियाँ

APIs जटिल कोड की वजह से नहीं टूटते।

वे इसलिए टूटते हैं क्योंकि आप उबाऊ विवरणों (boring details) को नज़रअंदाज़ कर देते हैं।

मैंने वास्तविक प्रोडक्शन एरर्स (production errors) से ये पाँच सबक सीखे हैं।

  1. डेटा को शुरुआत में ही वैलिडेट (Validate) करें

मैं अपने बिजनेस लॉजिक के अंदर डेटा वैलिडेट करता था। इससे सोर्स से बहुत दूर बग्स (bugs) आते थे।

अब मैं खराब रिक्वेस्ट्स (bad requests) को तुरंत रिजेक्ट कर देता हूँ।

यदि किसी रिक्वेस्ट में वैध ईमेल नहीं है, तो तुरंत 400 एरर रिटर्न करें। खराब डेटा को अपने मुख्य लॉजिक तक न पहुँचने दें।

  1. विशिष्ट एरर कोड्स (specific error codes) का उपयोग करें

एक सामान्य 500 एरर किसी की मदद नहीं करता।

यदि API key विफल हो जाती है, तो 401 एरर रिटर्न करें। यदि यूजर के पास क्रेडिट नहीं है, तो 402 एरर रिटर्न करें।

यदि आपको Slack पर किसी एरर को समझाने की ज़रूरत पड़ती है, तो इसका मतलब है कि आपका API मैसेज विफल रहा।

  1. अपने मिडलवेयर (middleware) का क्रम चेक करें

मैंने ऑथेंटिकेशन (authentication) समस्याओं को डीबग करने में घंटों बिताए। समस्या केवल मेरे मिडलवेयर का क्रम थी।

इस क्रम का पालन करें:

एक गलत लाइन सब कुछ तोड़ सकती है।

  1. सही डेटा लॉग (Log) करें

मैंने कई लॉगिंग स्टाइल आज़माए। उनमें से अधिकांश बेकार थे।

स्टैंडर्ड ट्रैकिंग के लिए, मेथड (method), पाथ (path) और स्टेटस कोड (status code) लॉग करें।

एरर्स के लिए, रिक्वेस्ट ID, एरर मैसेज और स्टैक ट्रेस (stack trace) लॉग करें।

जब आप रात के 3 बजे उठते हैं, तो इसके अलावा कुछ भी केवल शोर (noise) है।

  1. रेट लिमिट्स (rate limits) सेट करें

मैंने एक एंडपॉइंट (endpoint) को इतनी ज़ोर से हिट होते देखा कि उससे वास्तविक पैसा खर्च हो गया।

बिना लिमिट्स वाला API केवल उम्मीद पर टिका होता है। उम्मीद कोई सुरक्षा रणनीति (security strategy) नहीं है।

अपने सर्वर की सुरक्षा के लिए express-rate-limit का उपयोग करें।

अधिकांश API फेलियर बुनियादी बातों को नज़रअंदाज़ करने से आते हैं।

प्रोडक्शन को आपकी योजनाओं की परवाह नहीं है। उसे केवल आपके सेटअप (setup) से मतलब है।

Source: https://dev.to/manolito99/5-production-mistakes-that-changed-how-i-build-express-apis-133e