NestJS: A progressive Node.js framework for building efficient, reliable and scalable server-side applications.

NestJs : A progressive Node.js framework for building efficient, reliable and scalable server-side applications.
NestJs : A progressive Node.js framework for building efficient, reliable and scalable server-side applications.
A progressive Node.js framework for building efficient, reliable and scalable server-side applications.

NestJS is a backend framework for creating scalable applications and is a platform-agnostic framework. Therefore, we can create reusable components and can take advantage of different types of libraries and applications. It works as an abstraction over the underlying HTTP server library. Currently, it supports two libraries — Express[1] and Fastify[2] — while still enabling developers to use their own APIs when needed. According to your application needs, you can choose one of them. But by default, it uses express libraries as a platform as you see…

NestJs Architecture — Guards

We can say about the guards that they are the security management layers like Java/Spring Security. We can easily manage all of the authentication and the authorization mechanism, role-based access managements by using guards. There are many different ways of doing it in Node.js, but Guards are developed specially for it. They have a single responsibility, determine whether incoming request will be handled by the router or not according to specific condition (i.e., roles, permission, access control lists…) at run time.

Instead of using Guards, you may ask that why we don’t use middleware. We can still use middleware, but…

We create a pipe as a class with the @Injectable() decorator which should implement the PipeTransform interface. In general we use the pipes for the following cases:

  • Transformation: to transform input data to the desired form(i.e., string to JSON object, integer to string..)
  • Validation: to check the input data (e.g., JSON schema validation — if data is not valid, throw an exception..)
NestJs Architecture — Pipes

please click to go previous page || please click to go next page

NestJS comes with really strong exception management structures called Exception Filters. With this built-in exception management layer, we can handle all of the unhandled exceptions across the NestJS application. Therefore, if you don’t handle any exception in your code, it is caught by a built-in global exception filter, which handles exceptions of type HttpException. So, when exception is unrecognised, it generates the following default JSON response:

"statusCode": 500,
"message": "Internal server error"
NestJS Architecture — Exceptions

The usage of NestJS Exception filters are quite simple. Let’s have a look at it with a simple example as shown below:


import { HttpException…

Interceptors which have useful features that are inspired by Aspect Oriented Programming (AOP)[1] design pattern are classes annotated the @Injectable decorator and should implement the NestInterceptor interface. We can figure the usage of interceptors as shown below.

NestJS Architecture — Interceptors

As shown above, NestJS is able to trigger the interceptor before, after method execution, when the method throws an exception, when we want to override method response depending on any conditions (e.g., caching purpose) or want to extend of method functionality.

To create an interceptor is really easy. As we said above, interceptor class should implement the NestInterceptor interface. When you look at…

We can explain the middleware as a layer of code which is called before the route handler. We are able to access request object(req) and response object(res) and next function in the application’s request-response cycle by using middleware functions and by default NestJS middleware functions are equivalent to express middleware. Let’s have a look at what we can do by using express middleware:

  • Execute any code.
  • Make changes to the request and the response objects.
  • End the request-response cycle.
  • Call the next middleware in the stack.

The following figure shows the elements of a middleware function call:

Express middleware functions figure

We can implement…

In NestJS, providers have a vital importance. In general we can use the following classes as a provider:

  • Services: contains domain (business) logic.
  • Repositories: contains database CRUD operations
  • Factories
  • Helpers

and so on… objects can be used as a provider in NestJS application. The main key features of providers are that they can inject dependencies. It means that we can inject them to other classes, wherever we want easily. NestJS will manage the dependencies. As we said before, NestJS is inspired by Angular.js, therefore NestJS supports IoC(Inversion of Control) and DI(Dependency Injection). It manages providers lifecycle. …

Modules are another important one of the NestJS building blocks. We can isolate our component by using module classes. When we create new object in our application, NestJS don’t know it at first. To initialise and use it in our application, we need to register our objects to NestJS by using @Module() decorators. We can create a module object for each component as a separate class (suggested way), or also you can register all of objects in the app.mudule.ts class. Let’s have a look app.module.ts class as shown below:


import { Module } from '@nestjs/common';
import { AppController } from…

NestJS manages an application’s and it’s all of elements’ lifecycle. It provides lifecycle hooks that gives visibility into key lifecycle events and the ability to run registered code on our module, injectable or controller when they occur. We can say that NestJS divides the overall lifecycle into three phases: initialising, running and terminating. According to this lifecycle, we can plan for appropriate initialisation of modules and services, manage active connections, and shutdown our application when it receives a termination signal. We can explain it with the following diagram that is taken from the NestJS documentation:

NestJS Lifecycle events

Lifecycle events are triggered during…

Application Architecture — Controllers High Level

Controllers are the most important as a building block. They are the responsible for handling incoming requests and returning responses to the client. We are able to receive certain requests to the application, doing it with the routing mechanism. The routing mechanism manages which controller receives which requests with the following decorators:

Rasim Sen

Technical Training Coordinator at www.Zero2Hero.Training, Blockchain Developer(Oxford BC Strategy Programme Certified) and an AWS Certified Solution Architect.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store