我在使用 Express APIs 时犯过的 5 个生产环境错误
API 崩溃并不是因为代码复杂。
它们崩溃是因为你忽略了那些枯燥的细节。
我从真实的生产环境错误中吸取了这五个教训。
- 及早验证数据
我以前习惯在业务逻辑内部验证数据。这导致 Bug 出现时已经远离了源头。
现在我会立即拦截错误的请求。
如果请求缺少有效的电子邮件，立即返回 400 错误。不要让错误的数据进入你的核心逻辑。
- 使用具体的错误代码
通用的 500 错误对谁都没有帮助。
如果 API key 失效，返回 401 错误。如果用户余额不足，返回 402 错误。
如果你需要在 Slack 上解释一个错误，说明你的 API 消息设计失败了。
- 检查中间件顺序
我曾花了好几个小时调试身份验证问题。结果问题仅仅出在中间件的顺序上。
请遵循以下顺序：
- 首先是 CORS
- 其次是 JSON 解析
- 第三是身份验证
- 最后是路由
一行写错就会导致全局崩溃。
- 记录正确的数据
我尝试过很多日志记录风格。大多数都毫无用处。
对于标准追踪，记录 method、path 和 status code。
对于错误，记录 request ID、错误信息和 stack trace。
当你在凌晨 3 点醒来时，除此之外的一切都是噪音。
- 设置速率限制
我曾眼睁睁看着一个端点被疯狂调用，导致产生了实际的费用支出。
没有限制的 API 只能寄希望于运气。而“希望”并不是一种安全策略。
使用 express-rate-limit 来保护你的服务器。
大多数 API 故障都源于忽视基础。
生产环境不在乎你的计划。它只在乎你的配置。
来源：https://dev.to/manolito99/5-production-mistakes-that-changed-how-i-build-express-apis-133e