Express

routingとmiddleware chainを中心に、HTTP request処理を小さな責務へ分割する

Expressの中心は、HTTP methodとpathに応じてhandlerを選ぶroutingと、request/responseを順番に処理するmiddlewareです。READMEはrobust routing、HTTP helper、content negotiation、view systemを主要featureとして挙げています。認証、logging、validation、session、static file、API endpointなどをmiddleware単位へ分け、application固有のbusiness logicをHTTP transportから分離しやすい構成です。

ExpressはORMやtemplate engineを固定せず、必要な機能をmiddleware・packageとして追加します。full-stack規約を強制するframeworkよりも、HTTP layerだけを薄く組み立てたいprojectで採用しやすい設計です。

出典：[2]

Express 5ではasync handlerのrejected Promiseをerror handlingへ流しやすくする

Express 5のerror handlingでは、route handlerやmiddlewareが返したPromiseがrejectされた場合、そのerrorをExpressのerror flowへ渡せます。async function内でthrowされたerrorも同じ経路へ載せやすく、Express 4で必要だった手動のtry/catchやnext(error) boilerplateを減らせます。

一方、custom error handlerは通常のmiddlewareとはsignatureが異なり、(err, req, res, next)としてmiddleware stackの後段へ置く基本構造は変わりません。error responseのpolicy、logging、secret leakage防止はapplication側で設計する必要があります。

出典：[6][5]

API serverからserver-rendered Webまで、特定のdatabaseやview stackに縛られず使える

READMEはExpressをsingle-page application、website、hybrid、public HTTP APIに使えるframeworkとして位置づけています。response helper、redirect、caching、static file、content negotiationに加え、多数のtemplate engineを組み合わせられるため、JSON API専用frameworkではありません。

Node.js ecosystemのpackageを自由に組み合わせる前提なので、database access、validation、authentication、observabilityなどをproject要件に応じて選べます。既存Node applicationへ一部分だけrouting layerとして導入する構成も可能です。

出典：[2]

Node.jsでAPIやWeb backendを小さく始め、middleware単位で必要機能を足したいチームに

REST/JSON API、BFF、server-rendered Web、small serviceなどで、HTTP routingとmiddlewareを明示的に組みたいprojectに向きます。大規模frameworkの規約より、Node.jsの標準HTTP modelに近い薄い抽象化を好むチームや、既存packageを自由に選びたいチームでは扱いやすい選択肢です。

Express 5はNode.js 18以上。Express 4からはroute pathや削除APIを含むbreaking changeを確認する

Express 5はNode.js 18以上が必須です。migration guideは、基本APIはExpress 4に近い一方で互換性を壊す変更があると明記しています。app.del()、req.param()、旧res.send()/res.json() signatureなどが削除され、route path matching syntaxも変更されています。upgrade時はofficial codemodとautomated testを使い、単純なmajor version更新として扱わない方が安全です。

express.static()やres.sendFile()ではdotfile/hidden directoryの扱いも変わっています。.well-knownなどを配信しているapplicationでは、Express 4から5へ上げた際に404へ変わる可能性があるため、static file policyを明示的に確認する必要があります。

出典：[5][2]

minimalistである分、security・validation・authentication・rate limitはapplication側の設計責任が大きい

Express coreはroutingとHTTP helperを中心とするため、input validation、authentication/authorization、CSRF、rate limiting、secure cookie、TLS terminationなどを自動で完成させるframeworkではありません。公式security best practicesもTLS、user inputの検証、secure cookie、dependencyの安全性などを個別に設計するよう案内しています。

productionではtrust proxy、redirect target、file path、request body size、session storeなどの設定次第でsecurity postureが変わります。middlewareを追加するだけで安全になると考えず、reverse proxyとapplication双方のboundaryを確認する必要があります。

出典：[7][2]

5.2.1では5.2.0のquery parser変更をrevert。security情報はrelease noteとadvisoryを分けて読む

最新安定版5.2.1は、5.2.0で入ったextended query parserのbreaking changeをrevertしたpatch releaseです。release noteはこの挙動に実際のsecurity vulnerabilityはなく、CVE-2024-51999がrejectされたことを明記しています。security-relatedな変更に見えても、CVE番号だけで判断せず、official release note・security advisory・dependency updateを突き合わせる必要があります。

Expressは依存packageを複数組み合わせてHTTP behaviorを構成しています。framework versionだけでなくlockfileとtransitive dependencyの更新状況もproduction maintenanceに含める方が安全です。

出典：[4][3]