Express vs Fastify: middleware and throughput

Two philosophies: a chain vs an encapsulated plugin tree

Before picking a framework, ask yourself: do you need the widest possible ecosystem and the simplest mental model, or do you need schema-driven validation and serialization baked in? The answer usually decides the choice. Express is deliberately small: a request flows through a linear chain of middleware, each a (req, res, next) function that mutates req/res and calls next() to pass control along, or next(err) to jump to an error handler. There is almost no opinion baked in — you assemble routing, body parsing, auth, and logging from a vast ecosystem of app.use() middleware. That minimalism is its superpower: the largest middleware catalogue in the Node world, a decade of battle-testing, and a signature every Node developer already knows.

import express from "express";
const app = express();

// global middleware: runs for every request, in registration order
app.use(express.json());
app.use((req, res, next) => { req.startedAt = Date.now(); next(); });

app.get("/users/:id", (req, res) => {
  res.json({ id: req.params.id });
});

Fastify makes a different bet: a request runs through lifecycle hooks (onRequest, preParsing, preValidation, preHandler, …) and routes are grouped into plugins registered with fastify.register(). The defining feature is encapsulation — a plugin gets its own scope, so decorators, hooks, and middleware registered inside it do not leak to siblings. This is a feature for modularity, but it surprises Express refugees who expect app.use() to be global everywhere.

import Fastify from "fastify";
const app = Fastify({ logger: true }); // pino built in

await app.register(async (instance) => {
  // this hook only runs for routes inside this plugin scope
  instance.addHook("preHandler", async (req) => { req.startedAt = Date.now(); });
  instance.get("/users/:id", async (req) => ({ id: req.params.id }));
});

The real differentiator: schema-driven validation and serialization

Express has no built-in validation or serialization story — you reach for zod, joi, or express-validator, and you serialize with res.json(), which calls JSON.stringify. Fastify builds both into the route definition through JSON Schema. A request schema validates and coerces incoming params/query/body before your handler runs. A response schema is the throughput lever: fast-json-stringify compiles that schema into a specialized serializer function ahead of time, so it never walks an unknown object shape at runtime the way generic JSON.stringify must.

app.get("/users/:id", {
  schema: {
    params: { type: "object", properties: { id: { type: "string" } } },
    response: {
      200: {
        type: "object",
        properties: { id: { type: "string" }, name: { type: "string" } },
      },
    },
  },
}, async (req) => getUser(req.params.id));

That compiled serializer is the single most real-world-relevant win, because it speeds up every response, not just a synthetic empty route — and as a bonus, fields not in the response schema are stripped, so you can’t accidentally leak a passwordHash.

The Express 4 async-error trap

The sharpest failure mode is historical and still everywhere. Express 4 does not catch rejected promises from async route handlers. If an async handler throws (or awaits something that rejects), Express 4 has no await around your function, so the rejection becomes an unhandledRejection — which since Node 15 crashes the process by default — instead of reaching your error-handling middleware.

// Express 4 — BROKEN: rejection escapes to unhandledRejection
app.get("/u/:id", async (req, res) => {
  const user = await db.find(req.params.id); // if this rejects…
  res.json(user);                            // …Express 4 never catches it
});

// Express 4 — FIX: try/catch + next, or a wrapper like express-async-errors
app.get("/u/:id", async (req, res, next) => {
  try { res.json(await db.find(req.params.id)); }
  catch (err) { next(err); } // hand off to the error middleware
});

Express 5 (now released) fixes this: rejected promises from async handlers are forwarded to the error handler automatically, closing the gap. Fastify never had this problem — handlers are async by design, their rejections are awaited and routed to the setErrorHandler hook. If you are on Express 4, wrap every async handler (or adopt express-async-errors); the silent crash is the most common production bug in older Express apps.