When I joined Mooofarm, my Head of Engineering gave me access to all the backend repos and asked me to find any scope of improvements by EOD. Although the backend was structured well, and had BAO and DAO layers, what I saw was a loosely typed system without tests. Which was what I had proposed at EOD as my findings.
Later on for my first project, I was given full liberty to use whatever framework I wanted to, and my first choice was Nest.js. I had heard about Nest earlier from my friends using it to build the backend at their startup, and I mostly heard good things about it.
I remember proceeding with the scaffolding provided by the Nest team instead of searching for any boilerplate online. In my "initial commit" PR, my lead asked me to combine all controllers, services, and modules individually, instead of the original modular approach that the Nest team recommends. I didn't give it much thought then but in retrospect, it seems counter-intuitive to have gone with that approach.
Things I loved.
- Typesafety: Maybe I am too novice to understand why there was a backlash with TS and why DHH doesn't like TS, but I loved the development experience that comes with using TS and the amount of time it saves finding errors which had been hard to find if we used JS instead.
Built-in Swagger: Although it looks like a minor addition, the @nestjs/swagger library helped the team a lot. Before nest, we were using confluence documents as API contracts, @nestjs/swagger brought with it the ease of documenting API contracts and sharing them across the team with minimal code boilerplate.
Dependency Injection Container: Nest operates the same way as Angular/.NET where dependencies gotta be first added at the modular level and then injected into services. This helps you identify and limit the dependencies of a single module, thereby helping you write efficient tests.
Inbuilt Packages: The Nest team has done a wonderful job of wrapping up essential packages under the @nestjs/* library. Any popular ORM like mongoose/sequelize has its own @nestjs npm package that can be used. Psychologically, it gives you a sense of confidence and belief when you come across a "@nest" package for the utility that you're searching for.
Performance: The service we built using Nest, had an amazing performance in both dev and prod, serving requests <60ms when it was deployed on PM2, which already had multiple other services running on it.