Nestjs Vs Nextjs

Posted on  by admin

I know what you're thinking. When it comes to Node backend frameworks, Express is the undisputed king. Its un-opinionated and minimalistic approach means it's a super versatile tool for every use case.

  • If that's what you think, then of course, you'd be largely correct.
  • I've used Express for a number of projects and it's been..
  • It's been plenty fast and easy enough to work with.

The thing is, as the saying goes: "with great power comes great responsibility". In Express' case, this great power takes the form of having free rein over the architecture of your entire application.

This may seem like a massive plus at the start, but as your app continues to grow, it can come back to bite you if you've not thought it through well enough at the start.

  • What is NestJS I hear you ask?
  • It's a Node framework designed for building fast, reliable and (very importantly) scaleable applications.
  • It brings a robust architecture to the table (based on Angular) and uses TypeScript by default (although you can use JS if you wish).
1. Create universal applications quite easily
  • Perhaps what's more interesting about Nest, is what it doesn't do. It doesn't try to reinvent the wheel.
  • Under the hood, it runs on Express (by default) or Fastify and provides a very clean level of abstraction on top of these frameworks whilst also allowing you utilise the platform specific APIs directly.
  • Nest is like Express with batteries included.

As you may have thought, that sounded rather interesting so I decided to take a look deeper into what it was all about.

One of the things that blew me away when I first looked into Nest, was just how detailed and verbose their documentation is.

They cover just about every topic you can imagine and provide detailed instructions on everything from database connections with TypeORM or Mongoose through to Authentication & Authorisation right through to websockets.

If you can think it, you can almost bet it's in the documentation. They also allow you to convert all their code examples from TS to JS incase you decide you want to ditch the types.

Nest is a very versatile framework and it has so many useful features.

It has everything you'd expect from a backend framework such as the tools for building REST and GraphQL (using Apollo server) APIs.

It can also be used for server rendered applications using a rendering engine such as Handlebars or EJS.

Some of the more interesting features that is provides are a simple implementation of web sockets that uses Socket.IO server under the hood and has the ability to run cron-like tasks from inside your application.

For a full list of what Nest can do, I highly recommend looking at their documentation as what I've mentioned doesn't scratch the surface.

You may be thinking, this is all nothing new, Express can do all of these things and you'd be right!

They're absolutely possible with Express. In fact, a lot of the packages that Nest uses for these extra features are built on existing Node packages that work with Express. In my opinion, where Nest stands out as different is when it comes to the developer experience.

It's able to utilise all of these cool features, whilst also maintaining a consistent and testable architecture for your applications.

This also has the added benefit of reducing decision fatigue and allowing you to switch between Nest projects easily as they all follow the same format.

Alright, alright I hear you say. This is all well and good, but what does a project actually look like?

Great question! Let's take brief tour.. A module is a way of separating different features of your application.

Think: Auth, Users, Pets etc.

Each module can have child modules allowing you to split your application up per feature in a logical way.

Each application has a single App module to wrap them all.

The module's controller is what's responsible for handling incoming requests and responding to the client.

In the example below, you can see we've got a GET request and a POST request. You can perform login in these controllers but for more complex or reusable logic, we pass that off to a service.

A service is a type of Provider. A provider is a class that's annotated with the Injectable decorator.

This allows it to be injected at runtime to the necessary controllers. This loose coupling is one of the foundation principles of Dependency Injection which we will talk about in a moment.

For now, let's just note that services are for application logic, database interactions.. that kinda stuff. Nest takes advantage of a pattern called Dependency Injection.

If you're not familiar with the concept, you might find it useful to read about it here. The basic concept is that you decouple a class from the methods it requires (in our case a service which contains our methods).

This allows the class to request the decencies from a DI container instead of us telling them explicitly where they are.

Instead, it requests the service from this DI container based on the class' type.