Chapter 01 — What is NestJS? (And Why It Even Exists)
Chapter 01 — What is NestJS? (And Why It Even Exists)
Hey everyone! Welcome to Namaste NestJS! 🙏
Take a deep breath. You might have heard scary words like "enterprise framework", "dependency injection", and "decorators" — and thought NestJS is only for big serious companies. That's a myth. By the end of this chapter you'll see NestJS is just Express with a tidy room. If you can write a Node.js route, you can learn Nest.
So let's start with a very honest question... "What was wrong with plain Express in the first place?"
What we will cover:
- The pain of raw Express — how apps turn into spaghetti
- What NestJS actually is (and what it is NOT)
- Express vs NestJS — side by side
- The 3 building blocks: Controllers, Providers, Modules
- Why TypeScript + Decorators are the secret sauce
- How a request flows through Nest
- When to use NestJS (and when it's overkill)
- Common misconceptions beginners have
- Interview Questions
1. A Small Story First
Imagine two developers, Aisha and Rohit, both build a food-delivery API.
Rohit uses plain Express. Day 1, it's beautiful — one app.js, a few routes. Day 90, there are 4000 lines in random files, nobody remembers where the "apply coupon" logic lives, and every new feature breaks two old ones. 😩
Aisha uses NestJS. Day 90, her project still has neat folders: orders/, users/, payments/ — each a self-contained box. A new developer joins and is productive in a day. 😎
┌─────────────────────────────────────────────────────────────┐ │ SAME APP, 90 DAYS LATER │ ├─────────────────────────────────────────────────────────────┤ │ │ │ PLAIN EXPRESS 😩 NESTJS 😎 │ │ ───────────────── ───────────── │ │ app.js (4000 lines) users/ │ │ utils.js (everything) orders/ │ │ routes.js (chaos) payments/ │ │ "where is that code?!" "obvious where things go" │ │ │ └─────────────────────────────────────────────────────────────┘
Both apps work. But one scales with the team and one collapses under its own weight. NestJS is not about doing new things — it's about doing them in an organized, repeatable way.
That's the whole idea. Let's build it up slowly.
2. So What Exactly is NestJS?
Here's the one-line definition to remember:
┌─────────────────────────────────────────────────────────────┐ │ │ │ NestJS = A structured framework for building │ │ server-side Node.js apps, using TypeScript, │ │ with Dependency Injection built-in. │ │ │ │ It runs ON TOP of Express (or Fastify) — │ │ it does NOT replace them. │ │ │ └─────────────────────────────────────────────────────────────┘
In simple words: Nest doesn't throw away Express. Under the hood, Express is still handling the HTTP. Nest just wraps it in a clean architecture — modules, classes, and decorators — so your code has a predictable shape.
A simple analogy: Express is a pile of high-quality LEGO bricks. Powerful, but you must invent your own way to organize them. NestJS is the same bricks plus an instruction booklet and labelled trays. You build faster, and so does everyone after you.
Important — what NestJS is NOT:
❌ NOT a new language → it's just TypeScript ❌ NOT a replacement for Node → it runs on Node ❌ NOT only for huge apps → great for small APIs too ❌ NOT slower than Express → it IS Express underneath ✅ IS an opinionated way to organize a Node backend
3. Express vs NestJS — Side by Side
Let's write the exact same route ("GET /cats returns a list") in both, so the difference is crystal clear.
The Express way — everything in one function:
// Express — app.js
const express = require('express');
const app = express();
// route + logic all mixed together
app.get('/cats', (req, res) => {
const cats = ['Tom', 'Garfield']; // where's the "database" logic? right here, tangled in.
res.json(cats);
});
app.listen(3000);
The NestJS way — the same thing, but split into clear roles:
// cats.controller.ts — only cares about HTTP (routes)
import { Controller, Get } from '@nestjs/common';
import { CatsService } from './cats.service';
@Controller('cats') // 👈 this decorator = "all routes here start with /cats"
export class CatsController {
constructor(private catsService: CatsService) {} // 👈 Nest INJECTS the service for us
@Get() // 👈 handles GET /cats
findAll(): string[] {
return this.catsService.findAll(); // controller delegates — it doesn't do the work itself
}
}
// cats.service.ts — only cares about business logic (the actual data)
import { Injectable } from '@nestjs/common';
@Injectable() // 👈 "I can be injected into other classes"
export class CatsService {
findAll(): string[] {
return ['Tom', 'Garfield']; // in real life: a database call
}
}
Q: This is more code! Why is that better?
A: Because each file has one job. The controller never touches data logic; the service never touches HTTP. When your app grows to 200 routes, this separation is the difference between "easy to change" and "afraid to touch anything".
Here's the same comparison as a table:
| Plain Express | NestJS | |
|---|---|---|
| Structure | You invent it (everyone differs) | Given to you (everyone agrees) |
| Language | JS (TS optional, manual setup) | TypeScript first-class |
| Wiring code together | Manual require() everywhere | Dependency Injection (automatic) |
| Testing | Harder — logic tangled in routes | Easy — services are isolated classes |
| Learning curve | Low to start, painful at scale | Higher to start, smooth at scale |
| Best for | Tiny scripts, quick prototypes | Real apps, teams, long-lived projects |
4. The 3 Building Blocks (Your Whole Journey)
Almost everything in Nest is one of three things. Learn these three and 80% of Nest clicks into place.
┌─────────────────────────────────────────────────────────────┐ │ THE 3 BUILDING BLOCKS │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 1. CONTROLLER → Handles incoming requests │ │ "Which URL? Which HTTP method?" │ │ (the receptionist 🛎️) │ │ │ │ 2. PROVIDER → Does the actual work / logic │ │ (Service) "Fetch data, calculate, call DB" │ │ (the chef 👨🍳 in the kitchen) │ │ │ │ 3. MODULE → Groups related controllers + providers │ │ "The box that ties a feature together" │ │ (the department 🏢) │ │ │ └─────────────────────────────────────────────────────────────┘
Think of it like a restaurant:
Customer request ──→ 🛎️ Receptionist (CONTROLLER)
│ "Table for GET /cats"
▼
👨🍳 Chef (SERVICE / PROVIDER)
│ actually cooks the data
▼
🍽️ Food returned to customer (response)
The whole restaurant = one MODULE (e.g. "CatsModule")
We'll dedicate a full chapter to each: Controllers (Ch 03), Providers & DI (Ch 04), and Modules (Ch 05). For now, just remember the receptionist / chef / department picture.
5. Why TypeScript + Decorators? (The Secret Sauce)
Two things make Nest feel "magic". Let's demystify both.
(a) TypeScript gives every object a known shape. Your editor autocompletes, and bugs are caught before you run the code — not at 2am in production.
(b) Decorators — those @Something lines — are just labels that add behavior to a class or method. They tell Nest "treat this class as a controller" or "this method handles GET requests".
@Controller('cats') ← a label on the CLASS: "this is a controller for /cats"
↑
this @ symbol is a DECORATOR — a function that attaches metadata
@Get(':id') ← a label on the METHOD: "run me on GET /cats/:id"
findOne() { ... }
In simple words: a decorator is a sticky note you slap onto your code. Nest reads all the sticky notes when it starts up, and wires your whole app together based on them. (We open the hood on exactly how this works in Deep Dive 03.)
Pro tip: Don't be scared of decorators. You'll use maybe 15 of them 95% of the time. They're vocabulary, not magic.
6. How a Request Flows Through Nest (Big Picture)
Let's trace a single request by hand — GET /cats — so you see where each piece fits. (We'll add more checkpoints like Guards and Pipes in Season 2.)
LET'S TRACE IT BY HAND: GET /cats
──────────────────────────────────
1. Browser sends ──→ GET /cats
│
2. Express (inside Nest) receives the raw HTTP
│
3. Nest sees @Controller('cats') + @Get()
→ routes it to CatsController.findAll()
│
4. findAll() calls this.catsService.findAll()
(the service was INJECTED automatically)
│
5. Service returns ['Tom', 'Garfield']
│
6. Nest serializes it to JSON and sends it back
▼
Response: 200 OK ["Tom","Garfield"] ✔
Notice step 4: you never wrote new CatsService(). Nest created it and handed it to the controller. That "handing over" is Dependency Injection — the heart of Nest, and the star of Chapter 04.
7. When Should You Use NestJS? (And When Not)
NestJS is a tool, not a religion. Use the right tool for the job.
✅ USE NESTJS WHEN: • You're building a real, long-lived backend (APIs, SaaS) • A team of people will touch the code • You want testing, structure, and TypeScript out of the box • You'll need auth, databases, queues, websockets, microservices ⚠️ MAYBE SKIP NESTJS WHEN: • You're writing a 50-line throwaway script • A single serverless function is all you need • The team has zero TypeScript experience and no time to learn
Q: Is NestJS slower because of all this structure?
A: No. At runtime it's still Express (or Fastify, which is even faster). The structure lives in how you write code, not in extra work per request. The "cost" is a bit more upfront learning — which pays for itself the first time you scale.
8. Little Traps Beginners Fall Into
┌─────────────────────────────────────────────────────────────┐ │ COMMON MISCONCEPTIONS ❌ │ ├─────────────────────────────────────────────────────────────┤ │ │ │ "Nest replaces Express." │ │ → No. Express is running underneath by default. │ │ │ │ "Decorators are magic I can't understand." │ │ → They're just functions attaching metadata. │ │ │ │ "I must use classes for everything, it's OOP hell." │ │ → Classes give structure + DI. You get used to it fast. │ │ │ │ "It's only for Angular developers." │ │ → The syntax is Angular-inspired, but you need zero │ │ Angular knowledge. │ │ │ └─────────────────────────────────────────────────────────────┘
Interview Questions — Quick Fire!
Q: What is NestJS in one sentence?
"NestJS is a progressive Node.js framework for building efficient, scalable server-side applications. It uses TypeScript, is heavily inspired by Angular's architecture, and provides an opinionated structure with built-in dependency injection, running on top of Express or Fastify."
Q: Does NestJS replace Express?
"No. By default Nest uses Express as its underlying HTTP platform — Express still handles the actual request/response. Nest is an abstraction layer on top that adds structure, DI, and decorators. You can even swap Express for Fastify with a single line if you need more performance."
Q: What problem does NestJS solve that plain Express doesn't?
"Express gives you total freedom but no structure, so large codebases become inconsistent and hard to maintain. Nest solves that with an opinionated, modular architecture and dependency injection. This makes code more organized, testable, and easier for teams to scale — everyone follows the same patterns."
Q: What are the three core building blocks of a NestJS app?
"Controllers, which handle incoming requests and define routes; Providers — usually services — which contain the business logic and are injected where needed; and Modules, which group related controllers and providers into cohesive feature units. The root module bootstraps the whole application."
Q: Why does NestJS use decorators?
"Decorators let you attach metadata to classes and methods declaratively. For example, @Controller marks a class as a controller and @Get marks a method as a GET handler. Nest reads this metadata at startup to wire routes and dependencies together, which keeps the code clean and expressive."
Key Points to Remember
| Concept | Key Takeaway |
|---|---|
| What is Nest | Structured, TypeScript-first framework on top of Express/Fastify. |
| Core problem it solves | Express has no structure → big apps become spaghetti. Nest gives structure. |
| 3 building blocks | Controller (routes) · Provider/Service (logic) · Module (grouping). |
| Secret sauce | TypeScript (safety) + Decorators (declarative wiring) + DI (auto-wiring). |
| Performance | Same speed as Express — it IS Express underneath. |
| When to use | Real, scalable, team-built backends. Overkill for tiny scripts. |
What's Next?
In Chapter 02, we stop talking and start building. You'll install the Nest CLI, scaffold your very first project with one command, and we'll walk through every file the CLI generates — including main.ts, the bootstrap file — line by line. By the end you'll have a running server and understand exactly what created it.
Keep coding, keep shipping! See you in the next one!
Post a Comment