۵ اشتباه در محیط عملیاتی (Production) که با Express APIs مرتکب شدم
APIها به دلیل پیچیدگی کدها از کار نمیافتند.
آنها به این دلیل از کار میافتند که جزئیات خستهکننده را نادیده میگیرید.
من این پنج درس را از خطاهای واقعی در محیط عملیاتی آموختم.
1. دادهها را در همان ابتدا اعتبارسنجی کنید
من قبلاً دادهها را داخل منطق تجاری (business logic) اعتبارسنجی میکردم. این کار باعث ایجاد باگهایی در فاصلهای دور از منبع اصلی میشد.
حالا بلافاصله درخواستهای نامعتبر را متوقف میکنم.
اگر درخواستی فاقد یک ایمیل معتبر باشد، بلافاصله خطای 400 برگردانید. اجازه ندهید دادههای نامعتبر به منطق اصلی شما برسند.
2. از کدهای خطای مشخص استفاده کنید
یک خطای عمومی ۵۰۰ به هیچکس کمکی نمیکند.
اگر یک API key نامعتبر باشد، خطای 401 برگردانید. اگر کاربر اعتبار کافی نداشت، خطای 402 برگردانید.
اگر مجبور باشید یک خطا را در Slack توضیح دهید، یعنی پیام API شما شکست خورده است.
3. ترتیب middlewareهای خود را بررسی کنید
من ساعتها وقت صرف عیبیابی مشکلات احراز هویت کردم. مشکل فقط ترتیب middlewareهای من بود.
این ترتیب را دنبال کنید:
- ابتدا CORS
- دوم JSON parsing
- سوم Authentication
- در آخر Routes
یک خط اشتباه، همه چیز را از کار میاندازد.
4. دادههای درست را لاگ کنید
من سبکهای مختلفی از لاگگذاری را امتحان کردم. بیشتر آنها بیفایده بودند.
برای ردیابی استاندارد، method، path و status code را لاگ کنید.
برای خطاها، request ID، پیام خطا و stack trace را لاگ کنید.
هر چیز دیگری، وقتی ساعت ۳ صبح از خواب بیدار میشوید، فقط سر و صدا (noise) است.
5. محدودیت نرخ (rate limits) تعیین کنید
من شاهد بودم که یک endpoint چنان تحت فشار قرار گرفت که باعث ضرر مالی واقعی شد.
یک API بدون محدودیت، بر پایه امید بنا شده است. امید، یک استراتژی امنیتی نیست.
برای محافظت از سرور خود از express-rate-limit استفاده کنید.
بیشتر شکستهای API ناشی از نادیده گرفتن اصول اولیه است.
محیط عملیاتی (Production) به برنامههای شما اهمیت نمیدهد؛ بلکه فقط به تنظیمات (setup) شما اهمیت میدهد.
منبع: https://dev.to/manolito99/5-production-mistakes-that-changed-how-i-build-express-apis-133e