For quite some time now, our team of engineers at VAIRIX has been working on Node.js software development projects involving different types of frameworks, which include not only web frameworks, but also different ORMs.
Examples of some of these frameworks are Koa.js, Express.js, Hapi, Fastify, TypeORM, Objection+Knex, MikrORM, Prisma, among many others.
In this article, you will learn about the advantages and disadvantages of using NestJS based on our team’s first-hand experience.
So if you are considering NestJS for your upcoming project, this article will surely provide some insight to help inform your decision process.
Let’s dive in!
As we mentioned above, our team has been leveraging NestJS for a while. That said, this article will focus primarily on one of our most recent projects, where our team was fully in charge of the architecture design, applying NestJS as the technology of choice.
Recently, one of our clients entrusted us with the planning, design and implementation of their project. And one of their non-functional requirements was that the system needed to work around the Node.js ecosystem.
The first step in our process was to discuss where we should be deploying our infrastructure and how it should be managed. And given our team’s extensive experience in working with AWS and Terraform, this was an absolute no-brainer choice for us.
The next step involved a conversation around the ideal frameworks for the project and how to organize the project architecture itself.
Every single one of the frameworks mentioned in our introduction were considered by our team during our discussions. But once we arrived at NestJS as an option, the debate was pretty much over.
From our standpoint, most Node.js frameworks share the common pitfall of being un-opinionated.
This fact on its own is not necessarily a disadvantage. However, when dealing with with larger-sized projects, we could argue that all the flexibility involved in that quality could become a double-edged sword.
What differentiates NestJS is that it’s a highly opinionated framework, which to a large extent is helpful in many areas, where the developer no longer has to suffer from the mental fatigue that comes with continually thinking about things like “How do I organize this code?” or “What is the best place to put this in? The following image gives a visual representation of how in NestJS everything revolves around the modules:
Now, what happens when something does not have its own module, as is the case with Objection+Knex?
The answer seems simple: You just create said module.
But sometimes this may be more complex, since not all the modules have the same level of difficulty.
This leads us to the following considerations: “The Bad” and “The Ugly”.
Although the above “criticism” may seem enough to scare you away from working with NestJS, we still need to consider its benefits before we skip to conclusions.
So then, what is “The Good”?
Well, the truth of the matter is, as usual, that it depends.
If you have to work on a small project or a proof of concept, the answer seems obvious. The work and learning curve involved in NestJS will probably take more of your time than development itself.
For projects that are large, complex, or with many “working parts”, we believe that NestJS is a viable option, and specially if your team has experience not only with Node.js, but also with other technologies and languages.
Now we want to turn it over to you: Did you find the article helpful? Reach out to our team if you’d like to discuss your upcoming project needs in more depth.
Ready to get started? Use the form or give us a call to meet our team and discuss your project and business goals.
We can’t wait to meet you!