What Express Actually Adds

"Simple things should be simple, complex things should be possible." — Alan Kay

Part IV built a server by hand: a parser, a router, body handling, response composition. Every one of those was real work, and every one of them is work you would rather not repeat on your next project. Express is the layer that packages them — and the reason to have built them first is that you can now say precisely what it adds, which is a much shorter list than its reputation suggests.

Here is the whole of it. Express gives you routing (Part IV ch3), a small set of request and response helpers (ch5), mountable sub-applications, and one genuinely new idea: middleware, a composition pattern for the request lifecycle. Body parsing is included but is itself just middleware. Sessions, authentication, validation, database access and templating are not included at all.

That is a thin layer, and Express has always been proud of it. What makes it worth a Part rather than a paragraph is that the one new idea is unusually load-bearing: middleware is how authentication, logging, compression, CORS, rate limiting and error handling all attach to a request, and getting its ordering and control flow right is most of what makes an Express codebase pleasant or awful.

There is a second reason for care. Express 5 changed things that Express 4 tutorials still teach, including route pattern syntax that now throws at startup and error handling that used to hang. Everything in this chapter was measured against Express 5.2.1, and the differences are called out where they bite.

An Express app is a function

The least appreciated fact about Express is how little it changes about the interface.

Three consequences of that shape, all of which come up in real code.

An Express app can be mounted inside another Express app, because a (req, res, next) function is exactly what app.use accepts. Sub-applications are not a special feature; they fall out of the interface.

An Express app can be handed to http.createServer, and to anything else expecting a Node handler — a serverless adapter, a test harness, a http2 server. app.listen() is a convenience that creates the server for you.

Middleware and route handlers are the same kind of thing. The only difference is whether a method and path were specified. That uniformity is why app.use(express.json()) and app.get("/x", handler) compose without any special casing.

Middleware: the one genuinely new idea

Everything else Express does, Part IV built. This is the part that was not there.

Four rules govern that loop, and every Express bug in this area is a violation of one.

A layer must call next() or end the response. Doing neither hangs the request — no error, no response, until a timeout. This is the same failure as Part IV's handler that forgot res.end(), arriving through a different door.

Calling next() more than once is a bug. It advances the chain twice, which usually produces ERR_HTTP_HEADERS_SENT further along. if (bad) return next(err) — with the return — is idiomatic for exactly this reason, and it is the same missing-return shape as Part II's callbacks.

next(err) skips to error handling, jumping over every remaining normal layer. That is what makes short-circuiting work.

Error middleware takes four arguments, and that is how Express distinguishes it — by fn.length. It is an unusual piece of API design: the arity of your function is load-bearing, so a four-argument error handler written with three arguments silently becomes normal middleware and never runs.

The helpers

The res helpers are small, and one of them does something surprising.

Those content types are not invented; they are what Express 5.2.1 actually returns. Three things follow.

res.send with a string sets text/html. For an API returning a plain-text message, that is wrong and it is silent. res.json() for data and res.type("text/plain").send(...) for text are the honest forms. It matters for the reason Part IV ch5 gave: without nosniff, HTML is executed.

res.status() is chainable and sets nothing else. res.status(404) alone sends no response — a surprisingly common bug, because the line looks complete.

res.json sets the content type and serialises, which is the whole of it. There is no magic; it is the four lines above.

On the request side, Express adds req.params from the route pattern, req.query parsed from the query string, and req.body only if a body-parsing middleware ran. Two measured details worth carrying: req.params values are always strings — /users/42 gives "42" — and req.query produces an array for repeated keys, so ?a=1&a=2 gives { a: ["1", "2"] }. Code expecting a string gets an array whenever a client repeats a parameter, which is a validation bug waiting for its first user.

Routers are mountable apps

The composition idea again, one level up.

That path rewriting is the whole mechanism, and it has three practical consequences.

A router is reusable because it is prefix-agnostic. It declares / and /:id; where those live is the mounting application's decision, so the same router can serve /api/v1/users and /api/v2/users.

req.path is relative and req.originalUrl is absolute. Middleware that builds links or logs URLs wants originalUrl; routing logic wants path. Using the wrong one produces URLs missing their prefix — a bug that only appears once something is mounted, which is usually after the code was written and tested unmounted.

Middleware mounted with a path only runs for that prefix. app.use("/admin", requireAdmin) is scoped, which is the clean way to apply a policy to a subtree rather than repeating a guard on every route.

What Express does not add, and what version 5 changed

The list of absences is short and worth stating explicitly.

The version differences, all measured on 5.2.1, matter enough to be explicit:

// EXPRESS 4 -> 5, the changes that break existing code.

// 1. Async errors are now forwarded automatically.
app.get("/x", async (req, res) => { throw new Error("boom"); });
//    Express 4: request HANGS until timeout — next(err) is never called
//    Express 5: error middleware runs, exactly like a sync throw
//    => asyncHandler / express-async-errors wrappers are now unnecessary

// 2. Route patterns are stricter (path-to-regexp v8). These now THROW at startup:
app.get("/old/*", h);        // Error: Missing parameter name at index 6
app.get("/opt/:id?", h);     // Error: Unexpected ? at index 8

// 3. The replacements:
app.get("/new/*splat", h);   // req.params.splat is an ARRAY: ["a","b","c"]
app.get("/opt/:id{/:rev}", h);  // braces mark an optional group

The first change is the one worth internalising. A decade of Node advice about wrapping async handlers exists because of one missing .catch(), and if you are reading an Express tutorial that tells you to install express-async-errors, you are reading about Express 4. The second is why an upgrade is not free: the patterns fail at registration, so the process does not start, which at least makes them impossible to miss.

Common Mistakes

1. Registering authentication after the routes it protects. Order is the design, and nothing warns you.

2. A middleware branch that neither calls next() nor responds. The request hangs until a timeout, with no error.

3. Calling next() twice. The chain advances twice, usually surfacing later as ERR_HTTP_HEADERS_SENT.

4. next(err) without return. Execution continues into the success path as well.

5. An error handler with three parameters. Express identifies error middleware by arity; three makes it ordinary middleware.

6. res.status(404) with nothing after it. It sets a code and sends nothing.

7. res.send(string) for an API. It sets text/html, not text/plain.

8. Assuming req.query values are strings. A repeated key gives an array.

9. Using req.path where req.originalUrl is meant. Mounted routers see a rewritten path.

10. Following Express 4 advice on Express 5. Async wrappers are unnecessary, and /* and :id? patterns throw at startup.

Interview Corner

Hands-on

Summary

• An Express app is a (req, res, next) function, which is why it plugs into http.createServer and why sub-applications need no special support.
• Express adds routing, helpers, mountable routers and middleware — and middleware is the only genuinely new idea.
• A middleware layer must call next() or end the response. Neither means the request hangs with no error.
• next(err) skips to error handling, and error middleware is identified by having four parameters.
• Order is the design. Authentication registered after a route does not protect it, and nothing warns you.
• res.send(string) sets text/html — measured — which is almost never what an API wants.
• req.params values are strings; repeated req.query keys become arrays.
• A mounted router sees a rewritten req.path, with req.baseUrl as the prefix and req.originalUrl untouched.
• express.json() bounds the body at 100kb by default and returns 400 on invalid JSON, 413 when too large.
• Express 5 forwards async handler rejections automatically, and rejects /* and :id? patterns that Express 4 accepted.

This chapter treated middleware as a mechanism. The next treats it as a pattern — what belongs in a middleware and what does not, how to write one that is composable rather than merely reusable, the difference between middleware that decorates a request and middleware that makes a decision about it, and the ordering constraints that emerge once a real application has fifteen of them. The mechanism is thirty lines; using it well is the part that takes judgement.