Routing: How Express Decides Who Answers

In Post 2 we saw that Express is Node's req and res with the boring parts pre-filled, and that one of those boring parts is answering the question "which function should handle this request?" That question is routing, and this post is about how Express answers it — and the two or three ways it will quietly answer it wrong if you don't know the rules.

By the end you'll know how a path like /quotes/42?author=Ada gets picked apart, why the order you declare routes in matters more than it seems, and which old routing habits Express 5 no longer accepts.

How to follow along (nothing to install). This post's sandbox is a small quotes API with every route we're about to discuss, running on StackBlitz in a browser tab. Whenever you see a Try it box, do it right there — no local setup, no npm install. Open the Post 3 sandbox ↗ and keep it in another tab. The preview's front page lists every route. The preview can only send GETs, so for other methods there's npm run req -- POST /quotes in the terminal.

1. Routing is a list, and the first match wins

Here's the entire mental model. When you write this:

app.get('/quotes', listQuotes);
app.post('/quotes', createQuote);
app.get('/quotes/:id', getQuote);

Express builds a list, in that order. When a request arrives, it walks the list from the top and asks each entry two questions: does the method match? and does the path match? The first entry that says yes to both gets to run. Nothing else does. If nothing says yes, the request falls out of the bottom and Express sends its default 404.

Two things fall out of that immediately:

• Method and path are matched together. GET /quotes and POST /quotes are different routes with different handlers, even though the path is the same. That's not a trick, it's just two list entries.
• Order is part of your program. Same routes, different order, different behaviour. We'll break something with this in Section 3.

In the sandbox the last entry in the list is a catch-all that returns a JSON 404, so a miss looks like the rest of the API instead of an HTML error page:

// Anything that reaches here matched nothing above.
app.use((req, res) => {
  res.status(404).json({ error: `no route for ${req.method} ${req.path}` });
});

Try it: In the sandbox ↗ preview, open /quotes, then /nope. The second one hits the catch-all at the bottom. Now, in a second terminal (the + next to the terminal tab), run npm run req -- DELETE /quotes/2. Same path as a route that exists, wrong method, so it walks past app.get('/quotes/:id') and lands in the 404 too.

2. Route params: the :id in the path

Hard-coding /quotes/1, /quotes/2, /quotes/3 is obviously not the plan. A route parameter is a named placeholder segment:

app.get('/quotes/:id', (req, res) => {
  const id = Number(req.params.id);              // '2' -> 2. Without this, 2 !== '2'.
  const quote = quotes.find((q) => q.id === id);
  if (!quote) {
    return res.status(404).json({ error: `no quote with id ${req.params.id}` });
  }
  res.json(quote);
});

:id matches exactly one path segment, and whatever it matched shows up in req.params.id. You can have several: /authors/:name/quotes gives you req.params.name. Nothing magic — Express turned your path pattern into a regular expression and named the capture groups.

The thing to tattoo on your brain: route params are always strings. The URL is text, so req.params.id is '2', not 2. If your data uses numeric ids, quotes.find(q => q.id === req.params.id) will never match, and you'll stare at a 404 for an id you can see right there in the array. Convert on the way in, and decide what a non-numeric id means (here, a plain 404).

Try it: Open /quotes/2 in the preview, then /quotes/999, then /quotes/abc. Now in server.js delete the Number(...) wrapper so the line reads const id = req.params.id;. Save, refresh /quotes/2. It's a 404 now, and nothing in the code looks wrong. That's the string-vs-number bug in its natural habitat. Put the Number() back.

3. The order bug

Time to break something on purpose. The sandbox has two routes under /quotes/:

app.get('/quotes/random', (req, res) => { /* one random quote */ });
app.get('/quotes/:id',    (req, res) => { /* one quote by id  */ });

In that order, everything works. /quotes/random hits the first entry; /quotes/2 skips it (the segment isn't literally random) and hits the second.

Now swap them, so /quotes/:id is declared first. Ask for /quotes/random. Express walks the list, reaches /quotes/:id, asks "does random fit in a :id slot?" — and yes, it does, because a param matches any segment. So the id handler runs with req.params.id === 'random', finds no such quote, and you get { error: "no quote with id random" }. The random route never gets a turn.

No error, no warning. Just a specific route silently shadowed by a general one declared above it. This is the single most common routing bug in Express, and it gets more likely as the file grows and people add routes at the bottom.

The rule: specific before general. Literal paths above param paths, more segments above fewer, and anything that could swallow a whole segment (:param, wildcards) as low as it can go.

Try it: In the sandbox ↗, cut the whole app.get('/quotes/random', ...) block and paste it below the /quotes/:id route. Save. Refresh /quotes/random a few times: you'll get the "no quote with id random" 404 every time. Move it back above and it's random again. Same code, different order, different program.

4. Query strings: the part after the ?

Params are for which thing. Query strings are for how — filtering, paging, sorting. Express parses ?author=Ada&limit=2 into req.query for you:

app.get('/quotes', (req, res) => {
  let result = quotes;

  if (req.query.author) {
    result = result.filter((q) => q.author === req.query.author);
  }
  if (req.query.limit) {
    const limit = Number(req.query.limit);
    if (!Number.isInteger(limit) || limit < 1) {
      return res.status(400).json({ error: 'limit must be a positive integer' });
    }
    result = result.slice(0, limit);
  }
  res.json(result);
});

Notice the query string doesn't take part in matching at all. /quotes, /quotes?author=Ada and /quotes?nonsense=1 all hit the same route; the handler decides what to do with the extras. Three things worth knowing:

• Values are strings. Same lesson as params. req.query.limit is '2'.
• Anything can be missing or garbage. The client controls this. ?limit=abc is a normal Tuesday. Validate, and send a 400 that says what you wanted.
• A repeated key becomes an array. ?author=Ada&author=Grace gives req.query.author === ['Ada', 'Grace']. Our filter compares a string to an array, so it returns nothing. If you accept repeats, normalise with [].concat(req.query.author).

One Express 5 note: the default query parser is now the "simple" one, so ?page[size]=5 gives you a key literally named page[size], not a nested object. If you want nested parsing back, opt in with app.set('query parser', 'extended').

Try it: In the preview, open /quotes?author=Ada, then /quotes?limit=2, then /quotes?limit=abc (a 400 with a useful message). Now try /quotes?author=Ada&author=Grace: an empty array, because author is now a list. Fix it in server.js by filtering with [].concat(req.query.author).includes(q.author) and refresh.

5. Wildcards, optional bits, and what Express 5 changed

Sometimes a route needs to swallow the rest of the path: a file server, a proxy, a "catch everything under here." That's a wildcard:

app.get('/files/*path', (req, res) => {
  // req.params.path is an array of the matched segments.
  res.json({ segments: req.params.path, joined: req.params.path.join('/') });
});

/files/a/b/c.txt gives req.params.path === ['a', 'b', 'c.txt'].

This is where Express 5 bites people who learned on Express 4, because the path syntax underneath (a library called path-to-regexp) was tightened up. The changes you'll actually hit:

The good news: all three fail loudly when the server starts, not silently at request time. The error message even links to an explanation.

Two defaults that didn't change and still surprise people: matching is case-insensitive (/QUOTES/2 works) and a trailing slash is ignored (/quotes/2/ works). Both can be switched off with app.set('case sensitive routing', true) and app.set('strict routing', true), but the defaults are usually what you want.

Try it: Open /files/a/b/c.txt in the preview and look at the array. Then in server.js change '/files/*path' to '/files/*' and save. Watch the terminal: the server refuses to start and tells you exactly why. Change it back. Now try /QUOTES/2 and /quotes/2/ in the preview; both work.

The whole thing, live

Everything above is one file, server.js, with the routes deliberately declared in the order the post discusses them. The preview's front page lists every URL worth clicking.

👉 Open the live demo in StackBlitz ↗

Dig deeper

• Read the routing section of the official Express 5 migration guide. It's short and lists every path-syntax change with before/after examples.
• Skim the path-to-regexp README. That library is Express routing; once you see its syntax, :id, *path and {/:id} stop looking arbitrary.
• Look up app.route('/quotes'). It lets you chain .get(), .post() and .delete() for one path, which keeps related routes together in the list.

Try this too

Add DELETE /quotes/:id to the sandbox: remove the quote and reply with 204 and no body, or 404 if it doesn't exist. Test it with npm run req -- DELETE /quotes/2, then GET /quotes to confirm it's gone. Then add GET /quotes/latest (the highest id). Before you run it, decide where in the list it has to go, and why. If you get a "no quote with id latest" 404, you already know the fix.

Next up — Part 4: Middleware, the real mental model. Every route in this post was really a piece of middleware with a path attached. Next time we pull that thread: the (req, res, next) pipeline, why next() exists, and how express.json() from Post 2 actually works.

What Express Actually Is (and Why It Exists)

In Post 1 we figured out when to reach for Express and who's running it. Now the fun part: figuring out what it's actually doing for you. And the best way to appreciate a tool is to feel the pain it removes — so we're going to build a web server the hard way first, with raw Node, suffer a little, and then let Express ride in and save us.

By the end you'll be able to answer the question that quietly powers everything else in this series: what does Express do that plain Node doesn't? Get this right and middleware, routing, and error handling all click later instead of feeling like magic incantations.

How to follow along (nothing to install). This post's sandbox has both servers we're about to build, running on StackBlitz in a browser tab with Express already installed. Whenever you see a Try it box, do it right there — no local setup, no npm install, no pausing to get your machine ready. Open the Post 2 sandbox ↗ and keep it in another tab. npm start runs the Express server, npm run raw runs the raw-Node one, and npm run bad fires a deliberately broken request at whichever is running (you'll want that in Section 2).

1. A web server is just a function

Forget frameworks for a second. Underneath all of them, a web server is one embarrassingly simple idea:

A program that listens for incoming HTTP requests and, for each one, decides what response to send back.

That's it. And Node can already do this with zero dependencies, using its built-in http module:

// server.js — pure Node, no Express
const http = require('http');

const server = http.createServer((req, res) => {
  // This function runs once PER request.
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello from raw Node');
});

server.listen(3000, () => {
  console.log('Listening on http://localhost:3000');
});

Run it, open localhost:3000, and there's your text. That callback — (req, res) => {...} — is the entire web server. Every framework you'll ever touch, Express included, is just a nicer way of writing that one function.

Burn this picture into your brain: one function, two arguments. The request coming in, the response going out. We'll keep coming back to it.

Try it: In the sandbox ↗ terminal, run npm run raw. Open raw-server.js and find the / route near the top: it sends plain text the same way the snippet above does. Change its text to some HTML like '<h1>Hi</h1>' — but don't touch the Content-Type header. The preview shows the literal tags instead of a heading. That header is you, by hand, telling the browser how to interpret the bytes. Remember this annoyance; Express makes it go away.

2. Why raw Node gets painful, fast

The toy above works because it does exactly one thing. Real apps need to do different things for different requests. So let's add a couple of routes by hand and watch the whole thing get ugly in a hurry. (This is raw-server.js in the sandbox ↗, minus a landing route for the preview.)

const http = require('http');
const { URL } = require('url');

const server = http.createServer((req, res) => {
  const url = new URL(req.url, `http://${req.headers.host}`);

  // Route: GET /quotes
  if (req.method === 'GET' && url.pathname === '/quotes') {
    res.setHeader('Content-Type', 'application/json');
    res.end(JSON.stringify([{ id: 1, text: 'Stay curious.' }]));
    return;
  }

  // Route: POST /quotes  — now we collect the body ourselves. Joy.
  if (req.method === 'POST' && url.pathname === '/quotes') {
    let body = '';
    req.on('data', (chunk) => { body += chunk; });   // it arrives in pieces
    req.on('end', () => {
      const data = JSON.parse(body);                  // please be valid JSON
      res.statusCode = 201;
      res.setHeader('Content-Type', 'application/json');
      res.end(JSON.stringify({ id: 2, text: data.text }));
    });
    return;
  }

  // Nothing matched
  res.statusCode = 404;
  res.end('Not found');
});

server.listen(3000);

Look at the chores we just signed up for:

• Parsing the URL ourselves to find the path.
• A growing pile of if (method && pathname) branches.
• Manually buffering the request body out of a stream with req.on('data') and req.on('end'), then parsing JSON with zero safety net.
• Remembering to return after every response, or we'll try to send two and Node will yell at us.
• Handling "nothing matched" by hand.

Now imagine ten more routes, dynamic IDs like /quotes/42, login checks, and some logic that should run on every request. This file becomes a swamp. Every Node web framework on earth exists to drain exactly this swamp.

Try it: With npm run raw still going in the sandbox ↗, open a second terminal (the + next to the terminal tab) and run npm run bad. It POSTs the text not json to /quotes. Watch the first terminal: the whole process exits, because JSON.parse threw inside the callback and nobody caught it. One bad request, entire server down. (Locally the same thing is curl -X POST localhost:3000/quotes -d 'not json'.) Keep this in mind for Section 3.

3. The same thing, in Express

Here's the identical API, in Express. (This is express-server.js in the sandbox ↗, again minus the landing route.)

const express = require('express');
const app = express();

app.use(express.json());           // parse JSON bodies for us, automatically

let quotes = [{ id: 1, text: 'Stay curious.' }];

app.get('/quotes', (req, res) => {
  res.json(quotes);                // sets the header AND stringifies. both.
});

app.post('/quotes', (req, res) => {
  const quote = { id: quotes.length + 1, text: req.body.text };
  quotes.push(quote);
  res.status(201).json(quote);     // req.body is already parsed and waiting
});

app.listen(3000, () => console.log('http://localhost:3000'));

Same behavior, about a third of the code, and it reads like what it does. Look at what just vanished:

• No manual URL parsing — app.get('/quotes', ...) matches method and path in one go.
• No stream plumbing — express.json() handed us req.body.
• No setting Content-Type or calling JSON.stringify — res.json() does both.
• No 404 boilerplate everywhere — Express has a sensible default fall-through.
• And remember that crash from Section 2? Express's body parser catches the bad JSON and turns it into a clean error instead of taking the server down with it.

Here's the part to tattoo on your brain: Express isn't magic. It just already wrote all the boring code you were about to write. Every single thing it does, you could build yourself on top of http. It just did it first, did it consistently, and let a few million developers stress-test it.

Try it: In the sandbox ↗, stop the raw server (Ctrl+C) and run npm start. In the second terminal, run npm run bad again. This time you get a tidy 400 error response, and the server is still up — hit /quotes in the preview to prove it. That difference — staying up when handed garbage — is a real chunk of what you're "buying" with a framework.

4. The mental model: Express wraps req and res

This is the single most useful idea to lock in early, so we're slowing down for it.

When a request lands, Node still creates the same raw req and res objects from the http module. Express doesn't throw them out and replace them — it enhances them. It takes Node's request and response objects and quietly bolts convenience methods onto them:

So the res inside an Express handler is still Node's response object. You can literally call res.end() on it like before — Express just gave you a nicer set of tools sitting on top. Once this clicks, Express stops feeling like a black box and starts feeling like a helpful coworker who quietly pre-filled the tedious forms for you.

Try it: In express-server.js in the sandbox ↗, swap the res.json(quotes) line for a plain res.end('bye') and open /quotes in the preview. It still works, because the raw Node methods never went anywhere. Express layered on top; it didn't replace. Good to know the escape hatch is always there. (Swap it back when you're done.)

5. The request lifecycle, end to end

Let's trace one GET /quotes request through the Express app from Section 3, so you can see all the pieces line up in order. Blue steps are Express working for you; the green one is your code.

![One request, end to end: Browser sends GET /quotes; Node's http server creates the raw req and res; the Express app wraps them with extra methods; middleware runs in order (express.json sees no body and calls next); the matched route app.get('/quotes') runs your handler which calls res.json(quotes); the response is written back down the same socket as 200 OK with a JSON body; the browser shows it.]

Two ideas to carry forward, because the next two posts are built on them:

1. Routing is just "given this method and path, which handler runs?" That's all of Post 3.
2. Middleware is "functions that run in order, before or around your handler, each one able to touch req/res or pass control along." That express.json() line? That was your first piece of middleware, and Post 4 is entirely about this idea.

Try it: In express-server.js in the sandbox ↗, add app.use((req, res, next) => { console.log(req.method, req.url); next(); }); as the very first line after const app = express();. Refresh the preview a few times and watch the terminal: every request prints a log line before anything else happens. You just wrote middleware, and you saw the "runs in order, then calls next()" pattern with your own eyes. We'll obsess over that next() very soon.

The whole thing, live

Both servers are in one project, so you can flip between them and feel the difference: npm start for Express, npm run raw for raw Node, npm run bad to throw garbage at whichever is running.

👉 Open the live demo in StackBlitz ↗

Dig deeper

• Open Node's http docs and read the http.createServer and IncomingMessage pages. Everything Express does starts with those two objects.
• Look at Express's lib/response.js on GitHub and find res.json. It's about ten lines. Seeing how small the "magic" is changes how you debug it later.
• Search for "body-parser express.json". express.json() used to be a separate package, and knowing that explains a lot of older tutorials you'll run into.

Try this too

In the sandbox ↗, add one more route to raw-server.js by hand: GET /quotes/:id, returning the matching quote or a 404. You'll have to split the path, pull out the id, and convert it to a number yourself. Then do the same thing in express-server.js with app.get('/quotes/:id', ...) and req.params.id, and hit /quotes/1 in the preview. Feeling that difference in your fingers, not just reading about it, is the whole point of this post.

Next up — Part 3: Routing fundamentals. How Express matches paths, why route order quietly decides who wins, and how :params, wildcards, and query strings actually work once you stop guessing.

Why Express? Picking a Backend Without the Hype

Let's be honest about how most people meet Express. You're following some tutorial, it says npm install express, you paste a "Hello World," it works, and you have absolutely no idea why you chose this thing over the dozen other options that all promised to be the fast, modern, lightweight one.

This series fixes that. But before we write a single route, this first post is the part every tutorial skips: what Express actually is, when it's the right tool, when it isn't, and who's quietly running it in production. No code gymnastics yet — just the lay of the land so the rest of the series makes sense.

How to follow along (nothing to install). Every post in this series comes with a ready-made sandbox on StackBlitz: a full Node environment running in a browser tab, with Express already installed. Whenever you see a Try it box, you can do it right there — no local setup, no npm install, no pausing the tutorial to get your machine ready. This post's sandbox: Open the Post 1 sandbox ↗ Keep it open in another tab and poke at things as you read.

So what is Express, really?

Express is a minimal web framework for Node.js. That word minimal is the whole personality. Express doesn't tell you how to structure your project, where your database code goes, or how to name your folders. It hands you a clean way to say "when a request comes in for GET /users, run this function" and then gets out of your way.

People call this unopinionated. Translation: Express gives you a box of Lego, not a pre-built model. That's either liberating or terrifying depending on your mood, and we'll talk about both.

The mental one-liner to keep: Express is a thin layer that makes handling HTTP requests pleasant, and nothing more. Everything else — auth, validation, database access — you bring yourself or bolt on. That minimalism is exactly why it's lasted over a decade while flashier frameworks came and went.

The rest of the menu (your other options)

Express isn't the only game in town, and pretending otherwise would make me a bad tour guide. Here's the honest rundown of what else you'd consider, and the one-line reason you'd pick each.

Staying in Node.js land:

• Fastify — Express's spiritual successor for people who care about speed and built-in validation. If your bottleneck is genuinely the framework (rare, but it happens), this is the one.

• Koa — built by the original Express team as a "what would we do differently" project. Smaller core, modern async style. Elegant, but a thinner ecosystem.

• NestJS — the opposite of Express's philosophy. Heavily opinionated, TypeScript-first, structured like Angular. Big teams love it because it enforces consistency. Fun fact: by default, NestJS runs on top of Express under the hood. Even when you leave Express, you sometimes don't.

• Next.js / Remix — if you're building a React app and your "backend" is a handful of API routes, a full-stack framework might cover you and you may not need a standalone Express server at all.

Leaving Node entirely:

• Django / Flask (Python), Rails (Ruby), Laravel (PHP), Spring Boot (Java), Go's net/http. All perfectly good. The reason to stay with Express usually isn't that it's technically superior — it's that your frontend is already JavaScript and running one language across the whole stack is a genuine productivity win.

Try it (no code, just a gut check): Open the npm page for express, fastify, and koa and glance at the weekly download counts. You'll get an instant, visceral sense of how lopsided the ecosystem still is. We'll come back to what those numbers do and don't mean.

When Express is the right call

Reach for Express when:

• You're learning how the web actually works. Because it's so thin, Express teaches you HTTP instead of hiding it. That's the entire reason it's the backbone of this series.

• You're building a small-to-medium API and you want to make the structural decisions yourself rather than inherit someone else's.

• You need glue. A quick service, a webhook receiver, a proxy, a prototype you'll show someone on Friday. Express goes from zero to running in about four lines.

• You want a giant ecosystem. A decade of being the default means there's a middleware package for basically everything, and every Stack Overflow answer assumes you're using it.

When you should probably pick something else

I'm not here to sell you Express for every job:

• Huge team, huge codebase, lots of churn? Express's "do whatever you want" freedom becomes "everyone did something different." NestJS's guardrails earn their keep here.

• Throughput is your actual, measured bottleneck? Look at Fastify. (But measure first. It is almost never the framework. It's almost always your database.)

• Building a full-stack React app? Check whether Next.js already covers your backend before standing up a separate server.

The grown-up answer is that "best framework" is the wrong question. "Best framework for this job and this team" is the right one, and for a huge range of jobs the answer is still Express.

Does anyone serious actually use it?

Fair question, because "minimal and old" can sound like "hobby toy." It isn't.

Express is, by a wide margin, the most-downloaded web framework in the Node ecosystem — we're talking tens of millions of npm installs a week. It's been the de facto standard for Node backends since the early 2010s, which in JavaScript years is roughly an eternity.

Plenty of large companies have run it in production — Express's own community has long pointed to names like IBM, Accenture, and Uber among its users — but honestly the more telling fact is the invisible footprint. Because frameworks like NestJS sit on top of Express, and because it's the default in countless internal tools and microservices, you almost certainly used software today that had Express somewhere in the request path without anyone advertising it. It's plumbing. Good plumbing is the stuff you never notice.

The point isn't "it's popular so it's good." Popularity can be a trap. The point is that betting on Express is low-risk: the docs, the tutorials, the hiring pool, and the middleware all already exist.

A two-minute taste (don't worry, we go deep next time)

I promised not to drown you in code, so here's the smallest honest example of what Express feels like — just enough to see the shape of it. This exact file is what's running in the Post 1 sandbox ↗, so you can read along with it live:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello from Express');
});

app.listen(3000, () => console.log('Running on http://localhost:3000'));

That's a complete, working web server. Four meaningful lines. app.get('/', ...) reads almost like English: "when someone GETs the homepage, run this." Hold that feeling — in Post 2 we'll tear it open and see what Express is actually doing for you behind those four lines (spoiler: it's saving you from a lot of tedious plumbing).

Try it live: Open the sandbox ↗ (new tab, nothing to install), look at the preview on the right, then change the 'Hello from Express' string in index.js to your name. The server restarts on its own and the preview updates. Congratulations, you've shipped a backend. The bar was lower than the hype suggested.

👉 Open the live demo in StackBlitz ↗

The takeaway

Express won by being small and refusing to grow up into something complicated. It's the right pick when you value control, a gentle learning curve, and a massive ecosystem — and the wrong pick when you'd rather a framework make the hard structural decisions for you. Knowing which situation you're in is the actual skill, and now you've got the map.

Dig deeper

• Skim the official Express homepage. Notice how little it claims to do. That restraint is a feature.

• Look up "NestJS Express adapter" and confirm for yourself that the opinionated framework is riding on the unopinionated one.

Try this too

Two parts. First, in the sandbox ↗, add a second route: app.get('/about', ...) that sends a one-line description of you. Open /about in the preview. That's the whole pattern you'll be using for the rest of the series.

Second, and this one's on paper: think about the last app you built or used. Write down, in one sentence each: which framework you'd choose for its backend today, and why. Not "because it's popular" — the actual reason. That habit, picking tools on purpose instead of by default, is worth more than any single framework.

Next up — Part 2: What Express Actually Is. We strip away the convenience and build a web server with raw Node, feel exactly how painful it gets, and then watch Express make the pain disappear. That's where the "aha" lives.