What NestJS is and when to choose it

One POST /orders endpoint that checks its body and answers 201 or 400 takes 13 lines in one file with Express 5, and 45 lines in six files with NestJS 12, plus a compile step. Those counts come from the three versions this lesson runs side by side, and they raise the question it answers: what do the extra files give you, and when is Nest worth them?

You will see what Nest adds on top of Express or Fastify, follow one request through a Nest app, send the same three requests to all three versions, choose between Nest, Express, Fastify and Hono for a team and a workload, and read npm’s release tags before you pick a version.

Nest runs on top of Express or Fastify

Nest is not an HTTP server of its own. At start-up it reads your classes, then registers one route for each handler on an HTTP library underneath: Express 5 by default, or Fastify 5. That library parses requests and writes responses; the package @nestjs/platform-express 12.1.2 depends on express 5.2.1, and @nestjs/platform-fastify on Fastify. Nest calls this layer the HTTP adapterHTTP adapter: The part of Nest that wraps an HTTP library, Express or Fastify. Nest registers its routes on the library through it, and the library parses requests and writes responses. @nestjs/platform-express is the default..

On top of the adapter, Nest adds four things that a plain Express app leaves to you:

• Modules. A modulemodule: A class marked with @Module() that lists the controllers and providers that belong together, the modules it imports and the providers it shares with them. Every Nest app starts from one root module. lists the controllers and providers that belong together, so a feature lives in one place and states what it shares.
• Dependency injection. A class asks for what it needs in its constructor, and Nest’s container builds it and passes it in. This is dependency injectiondependency injection: A way of building objects in which a class asks for what it needs in its constructor and a container creates those objects and passes them in, instead of the class creating them itself., and the classes it builds are providersprovider: Anything Nest's container can create and inject, most often a class marked with @Injectable() such as a service. By default Nest creates one instance of each provider and shares it..
• Decorators for routes. @Controller('orders') and @Post() on a class and a method tell Nest which requests the method handles; such a class is a controllercontroller: A class marked with @Controller() whose methods handle requests. Each method with a route decorator such as @Get() or @Post() becomes one route of the app..
• A pipeline around every handler. Middleware, guards, interceptors, pipes and exception filters run before and after your method, in a fixed order. A pipepipe: A class Nest runs on a handler's argument before the handler, to check it or turn it into another type. A pipe that throws stops the request with an error response., for example, checks an argument before the method sees it.

Step through one request of this lesson’s Nest version, a valid order, and watch which of these layers runs where:

Two things in that walk are easy to miss. Your controller never touched the socket: Express parsed the body and wrote the reply, Nest chose the method and ran the pipe. And the method never saw the invalid body of the side branch, because the pipe answered 400 first. The rest of this track teaches each of these layers in turn.

The same endpoint, written three ways

Here is POST /orders for a tiffin service, TiffinTrail: a kitchen id and a number of meals from 1 to 10. Express 5 leaves the check to you, so the handler tests each field by hand:

// POST /orders in Express 5: parse the JSON body, check it by hand, answer 201 or 400.
import express from 'express';

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

let nextId = 1;

app.post('/orders', (req, res) => {
  const { kitchenId, meals } = req.body ?? {};
  const valid = typeof kitchenId === 'string' && Number.isInteger(meals) && meals >= 1 && meals <= 10;
  if (!valid) {
    res.status(400).json({ message: 'kitchenId must be text and meals a whole number from 1 to 10' });
    return;
  }
  res.status(201).json({ id: nextId++, kitchenId, meals });
});

Fastify 5 takes a JSON Schema on the route and checks the body before the handler runs:

// POST /orders in Fastify 5: a JSON Schema on the route, checked by Fastify before the handler runs.
import Fastify from 'fastify';

export const app = Fastify();

let nextId = 1;

const body = {
  type: 'object',
  required: ['kitchenId', 'meals'],
  properties: {
    kitchenId: { type: 'string' },
    meals: { type: 'integer', minimum: 1, maximum: 10 },
  },
};

app.post('/orders', { schema: { body } }, async (request, reply) => {
  const { kitchenId, meals } = request.body;
  reply.code(201);
  return { id: nextId++, kitchenId, meals };
});

The Nest version splits the same work into a schema, a provider, a controller and a module, plus app.ts, which switches on the validation pipe, and main.ts, which starts the server. The schema is a Zod object; Nest 12 checks any Standard SchemaStandard Schema: A common interface that validation libraries such as Zod, Valibot and ArkType implement, so that a framework can check data against a schema from any of them. Nest 12's StandardSchemaValidationPipe uses it. that @Body({ schema }) names once StandardSchemaValidationPipe is on:

import { Body, Controller, Post } from '@nestjs/common';
import { createOrderSchema, type CreateOrderInput } from './create-order.schema.js';
import { OrdersService } from './orders.service.js';

// The controller only translates HTTP: POST /orders becomes a call to OrdersService.create().
@Controller('orders')
export class OrdersController {
  constructor(private readonly orders: OrdersService) {}

  @Post()
  create(@Body({ schema: createOrderSchema }) input: CreateOrderInput) {
    return this.orders.create(input);
  }
}

import { Injectable } from '@nestjs/common';
import type { CreateOrderInput } from './create-order.schema.js';

// The business rule lives in a provider, which Nest creates once and hands to every class that asks for it.
@Injectable()
export class OrdersService {
  private nextId = 1;

  create(input: CreateOrderInput) {
    return { id: this.nextId++, ...input };
  }
}

import { z } from 'zod';

// The rule for the body, written once: Nest checks it, and TypeScript derives the type from it.
export const createOrderSchema = z.object({
  kitchenId: z.string(),
  meals: z.number().int().min(1).max(10),
});

export type CreateOrderInput = z.infer<typeof createOrderSchema>;

import { Module } from '@nestjs/common';
import { OrdersController } from './orders.controller.js';
import { OrdersService } from './orders.service.js';

// The module lists what belongs together: Nest builds the service and gives it to the controller.
@Module({
  controllers: [OrdersController],
  providers: [OrdersService],
})
export class AppModule {}

import { StandardSchemaValidationPipe } from '@nestjs/common';
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module.js';

// Builds the application without starting it, so main.ts and the comparison can both use it.
export async function createApp() {
  const app = await NestFactory.create(AppModule, { logger: false });
  app.useGlobalPipes(new StandardSchemaValidationPipe());
  return app;
}

import { createApp } from './app.js';

const app = await createApp();
await app.listen(process.env.PORT ?? 3000);

The session below compiles the Nest version, starts all three on ports the system picks, sends each the same three bodies, and counts the files and lines of each version:

import { session } from '../session.mjs';

// Compiles the Nest version, sends the same three requests to all three, then counts their files and lines.
session(`
npx tsc -p nest/tsconfig.json
node compare.mjs
node sizes.mjs
`);

$ npx tsc -p nest/tsconfig.json
$ node compare.mjs
POST /orders {"kitchenId":"pune-07","meals":3}
  express  201 {"id":1,"kitchenId":"pune-07","meals":3}
  fastify  201 {"id":1,"kitchenId":"pune-07","meals":3}
  nest     201 {"id":1,"kitchenId":"pune-07","meals":3}
POST /orders {"kitchenId":"pune-07","meals":11}
  express  400 {"message":"kitchenId must be text and meals a whole number from 1 to 10"}
  fastify  400 {"statusCode":400,"code":"FST_ERR_VALIDATION","error":"Bad Request","message":"body/meals must be <= 10"}
  nest     400 {"message":["meals: Too big: expected number to be <=10"],"error":"Bad Request","statusCode":400}
POST /orders {"kitchenId":"pune-07","meals":"3"}
  express  400 {"message":"kitchenId must be text and meals a whole number from 1 to 10"}
  fastify  201 {"id":2,"kitchenId":"pune-07","meals":3}
  nest     400 {"message":["meals: Invalid input: expected number, received string"],"error":"Bad Request","statusCode":400}
$ node sizes.mjs
express  1 file   13 lines  orders.mjs
fastify  1 file   16 lines  orders.mjs
nest     6 files  45 lines  app.module.ts, app.ts, create-order.schema.ts, main.ts, orders.controller.ts, orders.service.ts

The first body passes everywhere and the second fails everywhere, each with its own error shape. The third is the surprise: "meals": "3" is text, yet Fastify answered 201 and stored the number 3, because Fastify configures its JSON Schema validator with coerceTypes: 'array', which turns "3" into 3 before checking it. The hand-written check and Zod’s z.number() reject it with 400.

What the extra files buy, and what they cost

Nest’s six files are not six times the work, because each one has a single job and a fixed place. A new person on the team finds the rule for orders in OrdersService, the HTTP mapping in OrdersController and the wiring in OrdersModule, in every feature of every Nest app. The same structure carries over to GraphQL resolvers, WebSocket gateways and message-broker handlers, which use the same modules, providers and pipes. And because the controller receives its service through the constructor, a test can hand it a fake service without starting a server.

The costs are real, too:

The compile step deserves a word now, because it surprises people who run TypeScript directly with Node.js. Express and Fastify code is plain JavaScript, so node orders.mjs runs it. Nest code needs a TypeScript compiler to turn its decorators into function calls and to record the types of constructor parameters, which is why the session above ran npx tsc first. The last lesson of this module shows exactly what that compiler writes.

Choosing Nest, Express, Fastify or Hono for your case

The decision mostly comes down to three questions about your service. Answer them in the table below; it marks the frameworks your answers rule out or warn about, and the columns that decide:

In short:

• NestJS fits a team that will grow, a codebase that will live for years, or a service that will speak more than HTTP. It runs on a Node.js server through Express or Fastify.
• Express fits a small HTTP service or a quick prototype, and code that already depends on Express middleware. Express 5 is the library Nest itself uses by default.
• Fastify fits an HTTP service that wants checks declared per route and fast JSON handling with little code. Remember that it coerces types unless you configure its validator otherwise.
• Hono fits code that must run on an edge or web-standard runtime, such as Fastly Compute, Deno or Bun. Its handlers take the web-standard Request and return a Response.

Read the release line before you start

npm keeps a few named pointers for each package, its dist-tagsdist-tag: A name on the npm registry, such as latest or legacy, that points at one version of a package. npm install name@tag installs that version, and maintainers move tags by hand.. npm install @nestjs/core installs the version latest points at, and npm install @nestjs/core@legacy the one legacy points at. npm publish moves latest to each new release unless the maintainer names another tag, and every other tag moves only when a maintainer moves it, so a tag can be stale. This program reads a saved copy of the registry’s metadata for @nestjs/core and prints where each tag points and what each major line declares:

// Reads a saved copy of npm's metadata for @nestjs/core (registry-snapshot.json) and prints where each dist-tag
// points, then, for each major line, its stable releases, the newest one and what their engines fields declare.
import { readFileSync } from 'node:fs';

const meta = JSON.parse(readFileSync('registry-snapshot.json', 'utf8'));

function parse(version) {
  const [, major, minor, patch, pre = ''] = /^(\d+)\.(\d+)\.(\d+)(-.+)?$/.exec(version);
  return { major: Number(major), minor: Number(minor), patch: Number(patch), pre };
}

// Older first; a pre-release comes before the release it leads to (12.0.0-alpha.7 < 12.0.0).
function compare(a, b) {
  const x = parse(a);
  const y = parse(b);
  return x.major - y.major || x.minor - y.minor || x.patch - y.patch || (x.pre === y.pre ? 0 : x.pre === '' ? 1 : y.pre === '' ? -1 : x.pre < y.pre ? -1 : 1);
}

const stable = Object.keys(meta.versions).filter((v) => parse(v).pre === '').sort(compare);
const newestOf = (major) => stable.filter((v) => parse(v).major === major).at(-1);
const latest = meta['dist-tags'].latest;

console.log('dist-tags of @nestjs/core, newest version first:');
const tags = Object.entries(meta['dist-tags']).sort(([, a], [, b]) => compare(b, a));
for (const [tag, version] of tags) {
  const { major, pre } = parse(version);
  let note = '';
  if (pre) note = compare(version, latest) < 0 ? 'a pre-release, older than latest' : 'a pre-release';
  else if (newestOf(major) !== version) note = `${newestOf(major)} is newer on the same line`;
  console.log(`  ${tag.padEnd(7)} ${version.padEnd(15)} ${note}`.trimEnd());
}

// Every stable release of a line is read, so "all declare" is checked, not assumed from the newest one.
console.log('Stable releases of each major line, and what their engines fields declare:');
for (const major of [12, 11, 10]) {
  const line = stable.filter((v) => parse(v).major === major);
  const declared = [...new Set(line.map((v) => meta.versions[v].engines?.node ?? null))];
  let engines;
  if (declared.length > 1) engines = `mixed: ${declared.map((d) => d ?? 'none').join(', ')}`;
  else engines = declared[0] === null ? 'none declares engines' : `all declare node ${declared[0]}`;
  console.log(`  ${major}.x  ${String(line.length).padStart(2)} releases, newest ${newestOf(major).padEnd(8)} ${engines}`);
}

dist-tags of @nestjs/core, newest version first:
  latest  12.1.3
  next    12.0.0-alpha.7  a pre-release, older than latest
  legacy  11.2.7
  old     10.4.19         10.4.22 is newer on the same line
  beta    9.3.0-beta.3    a pre-release, older than latest
  rc      6.0.0-rc.1      a pre-release, older than latest
Stable releases of each major line, and what their engines fields declare:
  12.x   9 releases, newest 12.1.3   all declare node >= 20
  11.x  60 releases, newest 11.2.7   all declare node >= 20
  10.x  55 releases, newest 10.4.22  none declares engines

Read it from the top. latest is 12.1.3. next, beta and rc are old pre-releases that nobody moved forward, so npm install @nestjs/core@next would install an alpha of 12.0 that is older than every 12.x release. old points at 10.4.19 although 10.4.22 is newer on the same line; npm install @nestjs/core@10 asks for the newest 10.x instead. The engines field is the other thing to read: every 11.x and 12.x release declares node >= 20, and no 10.x release declares anything.

Walk through the three lines, oldest first, to see what each tag stands for:

The engines field is a floor, not the whole story. The migration guide asks for Node.js 20.19 or later, or 22.12 or later on the 22 line, to run a Nest 12 app, and the CLI’s code generators ask for 22.22.3, 24.15 or 26. The next lesson starts a project with Node.js 24.21.0, which meets both.

Practise: pick the framework

Each case below names a team, a workload and one constraint. Pick the framework that fits, then compare your reason with the explanation under the answer:

Interview questions

Key takeaways

• Nest registers its routes on Express 5 by default, or on Fastify 5; that library parses requests and writes the responses, and Nest adds modules, dependency injection, route decorators and a pipeline around every handler.
• The same endpoint took 13 lines in Express, 16 in Fastify and 45 lines in six files in Nest, and Nest’s version needs a compile step.
• The same body can get different answers: Fastify coerced "3" to 3 and answered 201, while the hand-written check and Zod’s schema answered 400.
• Nest pays off for teams, long-lived code and services that speak more than HTTP; Express and Fastify suit small HTTP services, and Hono suits edge and web-standard runtimes.
• npm’s dist-tags are pointers: npm publish moves latest, and every other tag moves only when a maintainer moves it, so check what latest, legacy and old point at, and the engines field, before you install.