Express.js

Category: Backend / Web Development

Learning Path: What → Why → Learning Modules → Production Example → Interview Prep

Before you start: you need basic Node.js comfort — running a script with node, installing packages with npm, and a working sense of require/import and the module system. You do not need prior experience with any other web framework, and this page does not re-teach Node itself — that's covered in this platform's own Node.js technology. See the Prerequisites tab for the full detail.

What is Express.js?

Node's built-in http module gives you the raw materials to build a web server, and nothing more — you get handed a request and a response object, and everything else is on you: parsing the URL to figure out which "route" was requested, checking the HTTP method, reading and parsing the request body if there is one, setting the right headers, and writing the response yourself. It's like being handed lumber, nails, and a hammer and told to build a house from scratch — technically everything you need is there, but nothing is assembled for you.

Express is a pre-built framework of doors, walls, and wiring on top of that raw material. You define routes (app.get('/users', ...)) and handler functions, and Express takes care of the repetitive plumbing — matching the URL and method to the right handler, parsing the body, managing headers, chaining reusable logic across requests. It is a minimal, unopinionated web framework — it doesn't force a particular project structure or a particular way of talking to a database, unlike some larger, more prescriptive frameworks. That minimalism, plus over a decade of being the default choice, is exactly why Express is the most widely-adopted Node.js web framework and the one most tutorials, job postings, and existing codebases assume you already know.

The core architectural idea behind Express is the middleware pipeline: every incoming request travels through a chain of functions before (and sometimes after) it reaches the function that actually handles it.

Why Express.js?

Writing route matching, body parsing, and header logic by hand with the bare http module is repetitive and genuinely error-prone the moment an app grows past a toy example — every route ends up re-implementing the same URL-parsing and method-checking logic, and it's easy to get subtly wrong (forgetting to handle a trailing slash, forgetting to set Content-Type correctly, forgetting to end the response). Express standardizes all of this into a well-understood, widely-documented pattern, so a developer joining a new Express codebase already knows roughly how requests flow through it.

The second reason Express still matters: despite newer, faster alternatives (Fastify, Hono, and others built with performance or modern TypeScript-first APIs in mind), Express remains the most common choice for a new Node API in practice. That's not inertia alone — it reflects genuine ecosystem maturity: an enormous number of existing middleware packages, tutorials, Stack Overflow answers, and production codebases already assume Express, and most backend job postings that mention Node.js also mention Express specifically. Learning Express first is still the highest-leverage choice for employability, even if a newer framework might be marginally faster on a benchmark.

Learning Modules

Module 01 — Routing & Request/Response Basics

Defining routes, reading request data, and sending a response

Topics covered:

Module 02 — Middleware, the Core Concept

The single idea that everything else in Express is built on

Middleware is just a function with the signature (req, res, next) — it runs somewhere in the chain before the final route handler, and it decides what happens next: modify req/res and call next() to pass control forward, or end the request itself by sending a response. A middleware that never calls next() and never sends a response is the single most common cause of a request that just hangs forever — Express is waiting for that function to do one of those two things, and it never will on its own.

Topics covered:

Module 03 — Error Handling & Building a Real API

Turning a handful of routes into a properly structured API

Topics covered:

Production Example

# Production Runbook -- "requests to POST /orders just hang, no response, no error"

# Step 1: Confirm it's actually hanging, not slow -- check for a timeout
# in the client, then reproduce directly against the server
curl -i -X POST http://localhost:3000/orders -d '{"item":"widget"}' \
  -H "Content-Type: application/json" --max-time 5
# curl: (28) Operation timed out -- confirms the server never responded at all

# Step 2: Add a log line at the very top of every middleware and the
# route handler itself, and watch which ones actually print
app.use((req, res, next) => {
  console.log("logger middleware hit:", req.method, req.path);
  next();
});
# If "logger middleware hit" never even prints for POST /orders, the
# route isn't matching at all (wrong path/method). If it prints once
# and nothing after it, the NEXT middleware in the chain is the culprit.

# Step 3: Inspect the suspect middleware for a missing next() or
# missing res.send()/res.json() on every code path -- including
# inside conditionals and try/catch blocks
app.use('/orders', validateOrderMiddleware);
# function validateOrderMiddleware(req, res, next) {
#   if (!req.body.item) {
#     res.status(400);   // <- sets the status but never actually sends anything
#     // MISSING: return res.json({ error: 'item is required' });
#     // MISSING: next() on the valid path too
#   }
# }

# Step 4: Fix -- every code path through a middleware must either
# call next() exactly once, or send a response. Never both, never neither.
function validateOrderMiddlewareFixed(req, res, next) {
  if (!req.body.item) {
    return res.status(400).json({ error: 'item is required' });
  }
  next();
}

# Step 5: Verify -- re-run the curl command, confirm a response comes
# back immediately, then check the happy path (valid body) still calls
# through to the actual route handler and returns 201/200 as expected

Interview Prep

PSR Formula: Answer every question: Problem → Solution → Result. 45-90 seconds max.

Common Interview Questions

Q1. What is Express and why use it instead of Node's built-in http module?

A: Problem: the bare http module requires manually parsing URLs, matching routes, checking methods, and parsing bodies for every single endpoint — repetitive and easy to get wrong at scale. Solution: Express provides a routing layer (app.get, app.post, etc.), a middleware pipeline for reusable cross-cutting logic (logging, auth, parsing), and built-in helpers (express.json(), res.json()) that remove that boilerplate. Result: the same API takes a fraction of the code to write correctly, and — just as importantly — is instantly recognizable to any other Node developer who's used Express before, which almost all of them have.

Q2. What is middleware in Express, and what is the next() contract?

A: Problem: many concerns (logging, authentication, parsing, error formatting) need to run across many or all routes, without duplicating that logic in every handler. Solution: middleware is a function (req, res, next) registered with app.use() (or scoped to specific routes) that runs before the final handler; calling next() passes control to the next function in the chain, while sending a response (res.send()/res.json()/res.end()) ends the chain there. Result: the contract is strict — every middleware must do exactly one of those two things on every code path, or the request hangs forever with no response and no error, which is one of the most common real Express bugs.

Q3. Why does error-handling middleware in Express need 4 arguments instead of 3?

A: Problem: Express needs a way to distinguish "this is a normal middleware" from "this is specifically for handling errors," without a separate registration API. Solution: Express inspects the function's arity — a middleware function declared with exactly 4 parameters, (err, req, res, next), is treated specially as error-handling middleware, and is only invoked when next(err) is called somewhere earlier in the chain (instead of plain next()). Result: this is a real, easy-to-miss gotcha — if you accidentally drop the err parameter, Express treats the function as regular middleware and it silently never gets called for errors, even though the code looks nearly identical.

Q4. Does Express automatically catch errors thrown inside an async route handler?

A: Problem: this is a genuinely important, commonly-misunderstood gotcha — a synchronous throw inside a regular route handler is caught by Express automatically and routed to error-handling middleware, but a rejected Promise from an async handler historically was not caught the same way in Express 4.x, which could crash the process or leave the request hanging. Solution: wrap async handlers in a try/catch that calls next(err) explicitly, or use a small wrapper utility that does this automatically for every async route. (needs verification — recheck against current source for the exact behavior in the Express major version actually in use, since this has evolved across versions) Result: treating every await in a route handler as something that must be explicitly caught and forwarded to next() avoids a whole class of production crashes that look mysterious without knowing this specific mechanic.

Q5. How do you organize routes in a larger Express application?

A: Problem: defining every route directly on the main app object doesn't scale past a handful of endpoints — the file becomes unmanageable and unrelated concerns get tangled together. Solution: express.Router() creates a mini, mountable Express app — routes for a specific resource (e.g. /users) are defined on their own router in their own file, then mounted onto the main app with app.use('/users', usersRouter). Result: this is the standard way real Express codebases stay organized — one router per resource, often paired with a separate controllers folder holding the actual handler logic.

Q6. What's a common ordering bug with Express middleware, and why does it happen?

A: Problem: Express matches and runs middleware and routes strictly in the order they were registered — top to bottom. Solution: if an authentication-check middleware is registered after a protected route instead of before it, that route runs completely unauthenticated, because Express never even reaches the auth middleware for that path — it already matched and returned a response. Result: this is why route/middleware registration order is treated as a genuine security concern in a code review, not just a style preference — a single misplaced app.use() can silently bypass a security control with no error anywhere.

Q7. What do helmet and cors actually do, conceptually?

A: Problem: a bare Express app doesn't set any of the HTTP security headers browsers use to enforce protections, and by default blocks nothing about cross-origin requests in a way a frontend developer would expect. Solution: helmet is middleware that sets a collection of security-related HTTP response headers (things that reduce clickjacking and certain injection risks) with sensible defaults; cors middleware explicitly controls which origins are allowed to call your API from a browser, since browsers block cross-origin requests by default unless the server opts in via CORS headers. Result: both are close to a checklist default for any real-world Express API — (needs verification — recheck exact recommended configuration/defaults against current source, since specific header recommendations do shift over time).

Q8. How would you validate a request body in Express?

A: Problem: trusting req.body without checking its shape means malformed or malicious input reaches business logic and the database layer unchecked. Solution: a validation library (commonly zod or joi in modern Express apps) defines the expected shape of the body, and a small middleware runs that validation before the route handler executes, responding with 400 and a clear error message if it fails. Result: this keeps validation logic out of every individual route handler and in one consistent, reusable place — exactly the kind of cross-cutting concern middleware exists for.

Q9. How do you connect an Express route to a database?

A: Problem: a route handler needs to read or write real data, not just return hardcoded values. Solution: inside the handler (or, in a well-structured app, inside a separate controller/service function the handler calls), use a database client or ORM to run the actual query, then send the result back with res.json() — wrapped in a try/catch (or the async-error-handling pattern from Q4) so a database failure produces a proper error response instead of a hang or a crash. Result: the database layer itself — connection pooling, query design, schema — is a large enough topic that it's covered in depth in this platform's own Databases academy rather than duplicated here; Express's job is just routing the request to that logic and shaping the response.

Q10. What's your experience debugging a real Express issue in production?

A: This is a genuinely personal question — answer with a real incident using the Problem → Solution → Result structure: what the symptom looked like (a hanging request, a "Cannot set headers after they are sent" crash, a CORS error a frontend team reported), how you actually diagnosed it (adding logging to isolate which middleware was responsible, checking registration order, reading a stack trace carefully), and what the actual fix was. Interviewers are listening for a real diagnostic process, not a memorized definition.

Official Resources

Try It (2 Minutes)

mkdir express-demo && cd express-demo
npm init -y
npm install express

Create server.js:

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

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

app.get('/greet/:name', (req, res) => {
  res.send(`Hello, ${req.params.name}!`);
});

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

Run it with node server.js, then open http://localhost:3000/greet/YourName in a browser. Change :name in the URL and refresh — that's Express's routing doing the work you'd otherwise have to parse req.url by hand to achieve with the bare http module.