Express vs NestJS: Choosing a Node.js Backend Framework

Two answers to the same question

Both frameworks run on Node.js, and both will serve an API perfectly well. They differ in how much they decide for you.

Express is a small library for handling HTTP requests. It has almost no opinions. How you organise files, validate input, connect to a database or test your code is up to you.

NestJS is a full framework built on top of Express. It prescribes a structure — modules, controllers, services — and wires the pieces together for you.

The same endpoint, twice

In Express:

import express from "express";

const app = express();
app.use(express.json());

app.get("/projects/:id", async (req, res) => {
  const project = await db.project.findUnique({
    where: { id: req.params.id },
  });
  if (!project) return res.status(404).json({ error: "Not found" });
  res.json(project);
});

app.listen(3000);

In NestJS:

@Controller("projects")
export class ProjectsController {
  constructor(private readonly projects: ProjectsService) {}

  @Get(":id")
  async findOne(@Param("id") id: string) {
    const project = await this.projects.findOne(id);
    if (!project) throw new NotFoundException();
    return project;
  }
}

The Express version is shorter and you can read it top to bottom. The NestJS version needs a service and a module alongside it — but it already tells you where the database logic lives, and the controller can be tested without a database at all.

For one endpoint, Express wins. The question is what happens at two hundred.

How they compare

	Express	NestJS
Structure	You design it	Provided
Getting started	Minutes	Longer; more concepts to learn
TypeScript	Supported	Built around it
Validation, auth, docs	Choose and wire up libraries	Built-in patterns
Testing	Depends on your structure	Dependency injection makes it straightforward
Consistency across a team	Needs discipline and conventions	Enforced by the framework
Splitting into services later	Manual	Supported out of the box

When Express is the better choice

• A small API with a handful of routes
• A prototype you may throw away
• A single-purpose service: a webhook receiver, a proxy, a scheduled job
• A team that already has strong conventions of its own

When NestJS is the better choice

• A backend several developers will work on for years
• A product with many areas — users, billing, notifications, reporting — that need clear boundaries
• A team that will grow, where new people need to find their way quickly
• A system that may later be split into separate services

The mistake in each direction

Express, outgrown. The app starts as one tidy file. Two years on it is forty files with four different ways of doing the same thing, and every new developer adds a fifth. The framework did not cause that — the absence of decisions did.

NestJS, too early. A three-route service wrapped in modules, providers and decorators is harder to read than the problem it solves.

Moving from one to the other

Because NestJS runs on Express underneath, a migration does not have to be a rewrite. Existing routes can keep working while new features are built as NestJS modules, and old ones are moved across gradually.

Our rule of thumb

If you can list every route on one screen and expect that to stay true, use Express. If the backend is the core of a product that will keep growing, start with NestJS — structure is much cheaper to begin with than to retrofit. It is the choice we make most often for custom software with a long life ahead of it.