2つの意味で使われる言葉
ミドルウェアは、話している人によって指すものが少し違う言葉です。
一つは、OSとアプリの間に入って橋渡しをするソフトウェアの総称。サーバーの構成図で「OS の上にミドルウェア、その上にアプリ」と書かれていたら、こちらの意味です。
もう一つは、Webアプリの中で、リクエストが届いてから本処理に入るまでの間、または返事を返すまでの間に挟み込む共通の処理。フレームワークを使った開発の話で出てきたら、たいていこちらです。
どちらにも共通しているのは、アプリの本体の外側で、みんなが必要とする処理を引き受けるという役割です。開発の相談で出てくるのは、たいてい後者です。
リクエストの通り道に置く共通の受付
会社の受付を思い浮かべてください。来客は担当部署へ行く前に、どの部署が相手でも、受付で訪問カードを書きます。不備があれば、担当者に会う前に受付で止めて確認する。担当部署は、手続きが済んだ来客を迎えることだけに集中できます。
Webアプリのミドルウェアも同じです。リクエストが本処理に届く前に、共通の手続きを挟みます。
- ログインが必要なページで、ログインしているかを一律に確かめる
- すべてのリクエストについて、アクセスの記録を残す
- 返事に、CORSの設定やセキュリティ関連の情報を一律に付ける
- エラーが起きたときの返し方を、アプリ全体でそろえる
本処理のコードに同じ確認を何度も書かずに済むので、重複が減り、抜け漏れも防ぎやすくなります。呼び出したときだけ働くライブラリと違って、リクエストの流れに自動で割り込むのが特徴です。
何でも受付に任せない
受付は、すべての来客が通る場所です。ここに時間のかかる手続きを置けば、どの部署への来客も待たされます。ミドルウェアに重い処理を入れると、サービス全体が遅くなるのと同じです。
受付の手続きには順番もあります。本人確認の前に部屋へ案内してしまっては意味がありません。ミドルウェアも登録した順に動くので、並べる順番を意識します。
詰め込みすぎると、今度は「なぜこの処理が動いているのか」「どこで止められたのか」が追いにくくなります。「どのリクエストにも本当に必要か」を基準にして、特定の処理にしか使わないものは、ミドルウェアではなく本体の側に書いておきましょう。