NodeでAPI dummyAPIとエラーハンドリング

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

1 初めに
2 Expressの構成（ファイル・システム）
3 エラーハンドリング用ミドルウェア　errorHandler
4 dummyAPI作成
5 終わりに

初めに

どもども！新卒期間がほぼ残り一月の平社員の龍ちゃんです。最近はブログ添削チームを作ろうと模索しています。本気のブログチームが欲しいところですね。

今回は、フロントエンドでエラーハンドリングの処理を実装するため、バックエンドを開発した内容についての技術ログを残していきたいと思います。今回勉強した内容としては、以下の内容になります。

Expressでのエラーハンドリング
「/test」のRESTFull Dummy API作成

今回参考にしたサイトは以下になります。

まったく経験ゼロベースからの構築になっていますので間違っている部分や回りくどい感じになっている可能性もあるのでご留意ください。今回作成した内容はこちらのリポジトリになります。

前回の勉強ログの記事を置いておきます。前段階を踏まえた構成がありますので、いったんそちらを読むことをお勧めしておきます。こちらは上司から訂正が入りそうなので、レビューが返ってきたら訂正しておきます。

Expressの構成（ファイル・システム）

今回の構成を図に示しておきます。前回記事の構成を踏まえて構築しています。ミドルウェアとしては「log用」「router用」「error用」の三つになります。エラーに来るルートを赤色で示しています。構成で特に注目してほしいのは以下の二点です。

errorHandlerでエラーの共通化
データのアクセスにはServiceを使用する

「errorHandlerでエラーの共通化」についてです。ミドルウェアでエラーを返答するように変更することでエラーの処理を一元化することができました。エラーの処理を簡単にすることは永遠の課題のように感じています。今回は割と単純にできたように感じているのであとの説明を読んでください。

「データのアクセスにはServiceを使用する」についてです。今回はdummyなのでデータはダミーなのですが、将来的にDBの接続などを考えているため処理として切り分けるために「service」というディレクトリを作成してデータの処理をすべてそのファイル内に記述しています。

今回のディレクトリ構造を以下に示します。「types」はTypescript用の型定義ファイルが含まれています。

エラーハンドリング用ミドルウェア　errorHandler

エラー用のミドルウェアがExpressに存在しています。こちらを設定することでエラーをキャッチできるミドルウェアが作成することできます。errorHandlerの全体コードを以下に出しておきます。

標準のErrorオブジェクトを拡張して、ステータスコードとメッセージを送信できるようにカスタマイズしています。ミドルウェアでエラーをキャッチして返信する仕組みになっています。返信自体はミドルウェアで返答するように一元管理しています。エラーが発生した場合は明示的に、「~Exception」のどれかを選択してエラーを投げてミドルウェアにキャッチさせます。

 if (res.headersSent) return next(err);

この部分では、すでにresponseで返答している場合は「next」で処理を継続させます。二重にエラーを吐かないようにする措置ですね。

具体的な使い方に関しては、次章の「dummyAPI作成」で説明を入れていきます。

dummyAPI作成

ここでは作成したdummyAPIについて解説していきます。まず、このファイルには「/test」のルーティングの場合しか入ってきません。簡易的なミドルウェアでHTTPメソッド判定を行っています。「GET/POST/PUT/DELETE」以外のメソッドの場合は、「notAllowedMethodExveption()」を「next」で出力されます。それ以降の処理にエラーが付属された状態でルーティング判定が走ります。最終的にエラーミドルウェアでキャッチされて、「405 not allowed method」が出力されます。

HTTPメソッド判定が無事に通り抜けることができた後は、それぞれのメソッドの処理に分岐していきます。個別の処理の場合でも同様にエラーが発生するタイミングで判定を挟み「next」でエラーを出力しています。

「next」は処理を継続することができます。ここは僕調べですが、「GET/POST/PUT/DELETE」に処理が入った場合は「next」を使用しない限り処理がそこで止まってしまいます。逆に「next」を使用することでその後ルーティングやミドルウェアの処理を継続させることができます。

データの処理はServiceに切り出していますが、アクセス系のエラーは「then~catch」で取得できるようになっています。catchで入ってきた場合でも同様にエラーを「next」で伝搬します。もしデータベースアクセス系のエラーが含まれる場合でもこれで処理することができそうです。

終わりに

今回は、フロントエンド開発のためのdummyAPIプロジェクトでした。共通エラーハンドリングで詰まったので調べて実装してみました。内容としては６時間ほどの内容になります。結構難しかったですが、一度実装しておけば使いまわせそうですね。当社の技術スタックにバックエンドをExpressを採用しているところがあるかは知りませんが….

とりあえず、これでフロントエンドのエラーハンドリングについては確認できそうです。

やっとで本業の部分に近づいてきましたね。それでは本業のフロントの記事で会いましょう。