The default choice for powering your Node.js is often Express.js. It’s a great choice — it’s lightweight, simple and popular with a vast ecosystem of libraries. However, it’s simplicity starts to have drawbacks once your app scales in complexity. These drawbacks can be solved with Nest.js, a web framework designed to support scalable web applications.
Nest.js can actually use Express.js under the hood, but it provides a higher-level abstraction on top of a lower-level HTTP framework. Nest provides really useful features like specifying routes with decorators, dependency injection (which makes database handling a breeze) and a module system.
Here’s a simple example of adding a controller with a GET /cats endpoint:
There are Nest libraries for your typical needs, like generating Swagger documentation automatically, adding GraphQL and socket.io integrations and support for a microservices architecture. If you’re missing something, you can of course extend Nest by yourself.
The main drawback of Nest.js is the added verbosity and complexity because you need to use the module system with separate controllers and services. Express.js is definitely simpler as it doesn’t make you architecture your app in a modular fashion.
TypeScript support is fantastic as Nest itself is written in it. You can even add type-safe runtime validators for user data to e.g. validate that the POST body matches the TypeScript interfaces. In addition, the TypeScript interfaces will be automatically used when generating the Swagger documentation. This makes TypeScript a really useful tool when implementing a Node.js backend.
I’ve used Nest.js in a multiple applications — big and small. My experience has been really positive — there hasn’t been any significant issues and the library is also being developed and maintained actively. In fact, if I’m starting a new application today, my default choice is now Nest.js instead of Express.js.