NX and NestJS what a lovely love story
Here we go again, doing some interesting discoverings with NestJS and NX Dev, last year and a few months i have been using nestjs to work in my current company, it was a nice way to start learning some cool stuff with back-end and go deep into typescript, because i used typescript time to time, when i usualy develop some new site with angular, off course the modular version, i was very used to went with the angular way, taking decorators and modular implementation really seriusly, especially the structure in order to mantain organization, therefore, i start learning nest and trying to acomplish a variety of back end proyects that i cannot coment detailed because of the top secret policy on my company, hence, once i get to understand the correct and balanced way that Nest JS uses to get things working it was “Beaaaauuutiful”, when finally understand reading the documentation that Nest is based in design by angular, what a great start i thought, thus, i get my hands real dirty with nest and all the tools we can use to work with on the development process.
Read more concerning NestJS in the official NestJS Documentation!
Then, Nest is angular-inspired in a variety of ways, but in the end, the beauty of a framework like Nest is that you can integrate the framework or library you love most, using express or fastify for a fast start, and then use Nest CLI to quickly build the components you need to get things working. Perhaps the main question is why you need to know and utilize this awesome framework.
Why use NestJS?
NestJS is a great tool for Angular developers because of its familiarity.
NestJS provides more structure, which helps large teams build complex backends more consistently than when using Express or other minimalistic frameworks.
In many ways, NestJS is also similar to Spring and .NET. So developers familiar with these technologies can use the hard-learned patterns and best practices when using NestJS.
NestJS is platform agnostic and supports REST, GraphQL, Websockets, gRPC, etc.. NestJS code can be reused when supporting multiple technologies or moving to a new technology. (Jean, 2019).
If you want to check out a quick introduction guide to NestJS, you can watch NestJS in 100 seconds; check out this introduction, created by Fireship.
Because of this, I rapidly became enchanted with NestJS, but I wasn’t sure if this was going to be my main framework to develop microservices. I’m always looking into new technology, trying to maintain the state of the art with the knowledge I get from new trends. Hence, in the mean time, several interesting technologies came up, Nx happened, and changed the whole paradigm of working with multiple projects in different git repositories. I saw this as a game-changing technology. If you are not familiar with the concept of monorepo, you can always check the explanation on the Internet, but here is a good description of what these monorepos are:
A monorepo is a version-controlled code repository that holds many projects. While these projects may be related, they are often logically independent and run by different teams. (Fernandez, 2022).
Back in the day, companies ran software using old infrastructure and sometimes bad practices; SOLID principles and Clean Code were not even mentioned in the companies where I worked. Time passes, and new architectural patterns emerge on the horizon for those who enjoy creating new software. Distributed systems gain market traction and become the de facto way to build new technology, The microservices paradigm emerges, and microfront-ends turn on the basis of scalable and fail-proof software built with built-in mechanisms. This is so “hot” divide and conquer; of course, you could do whatever you want distributing services here and there and doing the same with micro-front ends, but at the end of the day, if you start a project with 4 services and 2 micro-front ends, we got 5 or 10 new features, and maintaining these features we obtained or derived in 20 more, this is becoming a complete madness to maintain, not even taking into account all the people involved in the fix or feature task who need to. Hence, here is when NX comes to the rescue.
Nx is a smart, fast and extensible build system with first class monorepo support and powerful integrations.
Come on, NX! It’s love; it’s a completely game-changing framework that supports building scalable microservices, micro front-ends, and many more. I’m not going to go over all of the advantages of using this framework, but here are the main 6 reasons why we need to use this type of tool. (Read, 2021).
Well, the final idea of using NX is to get all the repositories you need to work in just one place — just one repository to rule them all! If you think about it in terms of a distributed system architecture, it’s an intriguing approach because you can get used to working with a variety of microservices. Let’s consider a hypothetical case with 8 microservices. Thus, it would be really awesome if you could have just one place to centralize the information — the main code in our case as developers for our microservices with NestJS — so here I am going to explain in brief steps how to do that. Sounds fun, right?
First you need to have this installed on your machine to get things working:
Already have installed NodeJS, Npm, and Npx
In this case the versions are very important, hence, here is going to be used the lastest version of each library and tool.
Therefore, generate with the NX documentation easily your first monorepo, for start you need to pick one main directory and open a terminal and run the following command:
npx create-nx-workspace
So, we have to finish our first monorepo with NX in 3 minutes for sure, then we can just use the NX console or check out our package.json to confirm the commands to run our base of microservices with NestJS.
nx serve is going to run the default proyect on nx.json file:
If this doesn’t work you can use nx console or run the following command:
nx run nest-ms:serve
Finally, on the folder structure, we have the apps folder. In that folder are going to be all applications that you add to this NX monorepo, so you can have reactJS, angular, nextJS, nestJS, and much more. NX is adding new support for a variety of frameworks and libraries.
I don’t recommend adding front-end applications to a monorepo with back-end applications because you may encounter problems with dependencies in the future. So the idea is to separate the concepts and, even more, separate the monorepo by feature, country, or experience; maybe another approach based on the analysis; well, that is another conversation, and we could and should debate what is the best approach to order or maintain the organization. That is all folks!, now, we can create and do what we love most, coding!.
Try it again. Fail again. Fail better (Becket, 2022)
If you liked this article and want to contact me, feel free to add me on LinkedIn
