𝟱 𝗘𝘅𝗽𝗿𝗲𝘀𝘀 𝗔𝗣𝗜 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗱𝗲 𝗪𝗮𝘁𝗮𝘀𝗵𝗶 𝗴𝗮 𝗸𝗼𝗺𝗮𝘀𝗵𝗶𝘁𝗮 𝟱𝘁𝘀𝘂 𝗻𝗼 𝗵𝗼𝗻𝗯𝗮𝗻 𝗸𝗮𝗻𝗸𝘆𝗼𝘂 𝗱𝗲 𝗻𝗼 𝗺𝗶𝘀𝘂

APIが壊れるのは、コードが複雑だからではありません。

退屈な細部を無視してしまうからです。

私は実際のプロダクションエラーから、これら5つの教訓を学びました。

  1. データのバリデーションは早めに行う

以前はビジネスロジックの中でデータをバリデーションしていました。そのせいで、発生源から遠く離れた場所でバグが発生していました。

今では、不正なリクエストは即座に遮断しています。

リクエストに有効なメールアドレスが含まれていない場合は、すぐに400エラーを返してください。不正なデータをメインロジックまで到達させてはいけません。

  1. 具体的なエラーコードを使用する

汎用的な500エラーは、誰の役にも立ちません。

APIキーが失敗した場合は401エラーを、ユーザーのクレジットが不足している場合は402エラーを返します。

Slackでエラーの内容を説明しなければならないとしたら、それはAPIのメッセージングが失敗している証拠です。

  1. ミドルウェアの順序を確認する

認証の問題のデバッグに何時間も費やしたことがありました。原因は単にミドルウェアの順序でした。

次の順序に従ってください：

たった一行の記述ミスが、すべてを台無しにします。

  1. 正しいデータをログに記録する

さまざまなロギングスタイルを試しましたが、ほとんどは役に立ちませんでした。

標準的なトラッキングには、method、path、status codeを記録します。

エラーについては、request ID、エラーメッセージ、およびstack traceを記録します。

午前3時に叩き起こされたとき、それ以外の情報はただのノイズでしかありません。

  1. レート制限を設定する

エンドポイントへの過剰なアクセスによって、実際に多額の費用が発生するのを目の当たりにしました。

制限のないAPIは「祈り」に頼っているようなものです。祈りはセキュリティ戦略ではありません。

サーバーを保護するために express-rate-limit を使用してください。

APIの失敗の多くは、基本を無視することから起こります。

本番環境はあなたの計画など気にしません。あるのはあなたのセットアップだけです。

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