So there I was…thinking on how to overengineer things to satisfy my ego and make my life harder…yet again — Anonymous coder
You might have come across NestJS and found yourself drawn to decorators, dependency injection, and queues.
However, it’s essential to consider whether these advanced features are truly necessary for your project. In many cases, the answer is no.
While these tools can be powerful, they may not always align with your needs. Instead, focusing on simplicity and understanding the core concepts of SOLID design, functional programming, and design patterns can lead to more effective and maintainable code.
As you navigate this exciting phase of your coding career, remember that the key to success lies in finding the right balance between advanced techniques and foundational principles.
By doing so, you’ll create predictable, simple, and repetitive code that stands the test of time.
One of the very few reasons I’d recommend someone to build something with NestJS, would only be to get a good understanding of how to make things modular.
Here is a detailed list of patterns NestJS can teach you as a newcomer and that you would find useful through your entire career.
While NestJS can be a powerful tool for building robust applications, it’s important to remember that after one good project, you may not need it anymore.
By exploring these key features and techniques, you’ll be better equipped to make informed decisions about when to use NestJS and when to move on to other tools and techniques.
I want to use NestJS because I want to do microservices with Node and I’ve heard it makes the process easier.
If you are starting a project the first thing you really want is simplicity and a streamlined process for connecting the dots.
Starting with a modular monolith is a smart approach. This strategy allows you to build a solid foundation for your application, making it easier to manage and maintain.
Starting with microservices from the get go is like trying to win a local race using a Lamborghini. It’s most likely overkill.
While NestJS can be a powerful tool for building microservices, it’s important to approach the project strategically.
Once the need arises, typically after a few years and with a growing user base, you can consider a more complex architecture like microservices. This approach can help you scale your application and improve its performance.
By starting with a modular monolith and only moving to microservices when the need arises, you can optimize your development process and build a robust application that meets your needs.
While certainly the Model View Controller design may have caught your interest, it is not really that big of a deal.
In MVC, the Model component serves as an Object-Relational Mapping (ORM) tool, facilitating interactions with database tables, collections, and entities in a declarative manner. This approach provides a more natural API for database operations compared to traditional raw queries.
// ORMs like Prisma, TypeORM, Sequelizer...You can use these on their own.
orm.User.findMany()
orm.User.createOne()
// vs
sql.query(`SELECT * FROM User`)
The View in MVC design is equivalent to the HTML of your application, providing the structure and layout for your frontend.
Popular templating engines like Handlebars and Pug can be used to streamline frontend development and create dynamic Views in your application.
A lot of people nowadays are moving towards more modern alternatives like React or Vue, which following a component architecture.
It’s worth noting that using the View component is not mandatory in NestJS, particularly when building backends.
doctype html
html(lang='en')
head
meta(charset='UTF-8')
meta(http-equiv='X-UA-Compatible', content='IE=edge')
meta(name='viewport', content='width=device-width, initial-scale=1.0')
title Pug Template Example
body
h1= title
ul
each item in items
li= item
The controller; routes.
// cats.controller.ts
import { Controller, Get } from '@nestjs/common';
@Controller('cats')
export class CatsController {
// GET /cats
@Get()
findAll(): string {
return 'This action returns all cats';
}
// GET /cats/:id
@Get(':id')
findOne(@Param('id') id: string): string {
return `This action returns cat #${id}`;
}
// POST /cats
@Post()
create(): string {
return 'This action creates a new cat';
}
// PUT /cats/:id
@Put(':id')
update(@Param('id') id: string): string {
return `This action updates cat #${id}`;
}
// DELETE /cats/:id
@Delete(':id')
remove(@Param('id') id: string): string {
return `This action removes cat #${id}`;
}
}
That’s the gist of it
You see, you are not missing on a lot.
You don’t really need classes at all.
I’ve seen plenty of codebases in node that have managed to do easier and more predictable state management, and modeling of entities without them.
All you really want…is an object and some methods here and there.
And for that…all you need is a function.
function createPerson(name: string, age: number): { name: string; age: number; greet(): void } {
return {
name,
age,
greet() {
console.log(`Hello, I am ${name} and I am ${age} years old.`);
},
};
}
const person = createPerson('John Doe', 30);
person.greet(); // Output: Hello, I am John Doe and I am 30 years old.
They are syntactic sugar as well btw. Don’t believe me? Well, time will tell.
Some NestJS fans will argue that it is impossible to live without decorators once you’ve tried them…I disagree.
At the end of the day, a decorator is nothing more than a function that takes in another function.
It basically sandwiches it.
function Delete(route: string) {
return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
const originalMethod = descriptor.value;
// Some wrapping logic
return descriptor;
};
}
// Used here
@Delete(':id')
remove(@Param('id') id: string): string {
return `This action removes cat #${id}`;
}
Although this may look like composition, it is in fact a completely different thing.
I am not against decorators.
I think they are useful but can turn out to be dangerous if you mutate a lot inside of them.
At the end of the day, you can achieve everything decorators do just with a simple function.
Finally, let’s say you decided to ignore this post completely and decide to build something using NestJS.
After getting over the learning curve, installing all the additional plugins they mention in their docs, maybe even purchasing its devtools, cruding here and there…it finally hits you.
You thought it was a swiss army knife, but you already had that (js + knowledge + you = swiss army knife).
All you did was just solidify you knowledge and understand that the best framework…is no framework at all.
Another piece in your programming nirvana quest achieved.
If you liked this content I’d appreciate an upvote or a comment. That helps me improve the quality of my posts as well as getting to know more about you, my dear reader.
Muchas gracias!
Follow me for more content like this.
X | PeakD | Rumble | YouTube | Linked In | GitHub | PayPal.me | Medium
Down below you can find other ways to tip my work.
BankTransfer: "710969000019398639", // CLABE
BAT: "0x33CD7770d3235F97e5A8a96D5F21766DbB08c875",
ETH: "0x33CD7770d3235F97e5A8a96D5F21766DbB08c875",
BTC: "33xxUWU5kjcPk1Kr9ucn9tQXd2DbQ1b9tE",
ADA: "addr1q9l3y73e82hhwfr49eu0fkjw34w9s406wnln7rk9m4ky5fag8akgnwf3y4r2uzqf00rw0pvsucql0pqkzag5n450facq8vwr5e",
DOT: "1rRDzfMLPi88RixTeVc2beA5h2Q3z1K1Uk3kqqyej7nWPNf",
DOGE: "DRph8GEwGccvBWCe4wEQsWsTvQvsEH4QKH",
DAI: "0x33CD7770d3235F97e5A8a96D5F21766DbB08c875"