Structure is what a backend needs in its third year, not its first.
Most backends are pleasant to work on for six months. The trouble starts later, when the person who wrote it has left and three people are adding features at once. By then nobody is sure which file decides who may approve a discount.
NestJS is the backend framework we start most new systems from. It settles the shape of the code before anybody has an opinion about it, which is the whole point.
NestJS is a framework that sits on top of Node.js and tells the code where to live. Every feature becomes a module with its own routes, rules and database access. Permissions, validation and error handling are declared once and applied everywhere, instead of being copied into each new endpoint by whoever wrote it.
Where it earns its place.
What it adds to plain Node
- A module per feature, so a new developer can find the invoicing code
- Validation on the way in, declared next to the field it guards
- Permission checks applied by the framework rather than remembered by hand
- Dependency injection, which is what makes the code testable
- One error format across every endpoint
- Generated API documentation the mobile developer can read
Where we use it
The backend under most of the systems we build, and the reason the mobile app and the web portal obey the same rules.
- SaaS platforms with several tenants
- CRM and ERP backends
- APIs for React Native apps
- Approval and workflow engines
- Integrations with Tally, WhatsApp and payment gateways
- Reporting endpoints
How the access rules get enforced
Guards run before your code does, so a permission cannot be forgotten in one endpoint out of forty.
- One place that decides what a role may do
- The same check on the web portal and the mobile app
- A tenant boundary applied to every query, not every screen
- Tokens issued, refreshed and revoked in one module
- An audit trail of who changed which record
The rules themselves still have to be agreed with you. The framework decides where they live, not what they say.
The work on a NestJS codebase
- Modules
- Schema
- Endpoints
- Guards
- Tests
- Deploy
- A module boundary per part of the business, drawn early
- Prisma over PostgreSQL, with migrations that can be run again safely
- Endpoints documented as they are written, not before a handover
- Automated tests on the rules that would cost money if they broke
- Deployment in Docker behind Nginx
When plain Node is enough
NestJS costs something: more files, more ideas to learn, and a week before a new developer is comfortable.
- A single webhook receiver
- A scheduled script that moves a file
- A prototype you intend to throw away
- A small service with one job and one caller
We have written plenty of small Node services with no framework at all. Structure is worth paying for when several people and several years are involved.
When this is the right choice.
- The system will be maintained for years by people who did not write it
- A web portal and a mobile app share one set of rules
- Several roles hold different permissions over the same records
- TypeScript across the browser, the server and the app
- The backend will grow feature by feature rather than ship once
When it is not.
- A working Laravel or PHP backend, where adding a second language buys nothing
- A backend whose main job is machine learning, since the libraries are in Python
- One small endpoint or a nightly script, where the structure is larger than the job
- A team you have already hired who write PHP and will maintain this themselves
Questions we are asked about it.
Is NestJS better than Express?
They are not really alternatives, because NestJS runs on Express underneath. The question is whether you want the structure it imposes. On a small service it is overhead. On a system that grows for years it is the reason the code stays readable.
Why not Laravel?
Often Laravel is the right answer, particularly when you already run PHP and employ people who write it. We build in both. NestJS wins when the same TypeScript types are shared with a React front end and a React Native app.
Do we have to use TypeScript?
In practice yes, and it is a benefit rather than a cost. Types catch a whole class of mistake while the code is being written, instead of when a member of your staff hits it. NestJS is built around them.
Can you take over a NestJS project somebody else started?
Yes. We read the code, write down what it actually does, and hand you a list of what is safe, what is fragile and what is missing before we touch anything.
Which database does it use?
Whichever suits the data. We usually pair it with PostgreSQL through Prisma, and it sits on MySQL just as happily when that is already running under your business.
Where does it run?
A Node process behind Nginx on a plain Ubuntu server, usually inside Docker. It also runs on managed platforms if you would rather not keep a server of your own.
Services that use it.
What it sits with.
Not sure NestJS is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private