Pacing fast into nest

Recent blogs

Standing on the Shoulder of Giants

February 19, 2025

Out of Sight but Never Out of Mind

February 19, 2025

The Enigma

January 8, 2025

cats-app using NestJS

Last dispatch we inspected the tooling required for the application built using NestJS. For those who have landed directly on this dispatch; NestJS is Angular’s equivalent for backend services. In this dispatch we will inspect the various elements that make up a NestJS application.

Our Oblog – Third dispatch

These are the elements which work hard together to render back the rocking data on your cool UI built in angular. In this dispatch we observe how in code these relationship ties together.

Listener

Typically, this should be a web server in production environment. For developers to test and work with application in lower environments there is a default express listener which can be initialized in code. The rituals to perform a production hosting can be a topic of discussion in separate dispatch. The nuances of such a hosting involves the landing zone where the code is deployed. For those starting with nest we recommend you continue with this express listener. Main.ts in the cats-app\src has the responsibility of creating a listener.

import {NestFactory} from ‘@nestjs/core’;
import {ApplicationModule} from ‘./app.module’;
async function bootstrap() {
const app = await NestFactory.create(ApplicationModule);
await app.listen(3000);
}
bootstrap();

There are two underlying platforms which are supported in Nestjs – Express and Fastify. Default one use is Express. You could flip it to Fastify.

Line 5 is a shortened form for the following syntax

const app = await NestFactory.create<NestExpressApplication>(ApplicationModule);

Had you wished to use Fastify there will be a bit of change which looks like below –

import {NestFactory} from ‘@nestjs/core’;
import {
FastifyAdapter,
NestFastifyApplication,
}
from ‘@nestjs/platform-fastify’;
import { ApplicationModule } from ‘./app.module’;
async function bootstrap() {
const app = await NestFactory.create<NestFastifyApplication>(
ApplicationModule,
new FastifyAdapter();
);
await app.listen(3000);
}
bootstrap();

Acute observation of the code will make us query many lines but let us hold till we finish up with other elements in the landscape.

Middleware

A request from the customer flows to the server through listener. But before the route handler; the one which determines what code to execute handles the request, middleware gets the request. Middleware as a concept is implemented in the express library which we saw in the listener element. Middleware’s generally are not single instances. Multiple middleware instances are chained with each other using a design pattern well known as “Chain of Responsibility” pattern. In the cats-app middleware that you could observe is –

import {Injectable, Middleware} from ‘@nestjs/common’;
@Injectable()
export class LoggerMiddleware implements NestMiddleware {
use(req: any, res: any, next: () => void) {
console.log(`[${context}] Request…`);
next();
}
}

Like observed earlier few interesting points for the dispatches to come are import statement, Injectable, NestMiddleware, arrow functions. What is more interesting to note the implementation of Chain of Responsibility^[1] pattern at Line 7. Where next in chain of the processing responsibility is called. If you note like in the pattern the next responsible processor is passed as function parameter to the middleware. Post processing the middlewares, framework evaluates the guards before handing the request out to routes.

Guards

This element also appear before route handler is invoked. This element intercepts request to validate if a route handler can be called or not. They are used to validate a request which forms best case for authorization and authentication. For brevity you will notice code resembling this in the cats-app –

…
canActivate(context: ExecutionContext): Boolean {
const roles = this.reflector.get<sring[]>(‘roles’, context.getHandler());
if(!roles) {
return true;
}
….

The only responsibility these elements carry is to determine if the route handler to which they are attached can be executed or to be skipped. They have the visibility to context only. After determination the possibility to process the route; request goes to the route. However, before reaching to the controller there are few more elements which work upon the request.

Interceptors

Like the name indicates they intercept before the actual controller logic executes. This element is processed on the request as well in the response. Thus, both request and response can be inspected, and transformed in this element. Use cases which involve transformation of request as well as response find interceptor as ideal place to write logic. In the cats-app you might find a code that resembles to –

import {
CallHandler,
ExecutionContext,
Injectable,
NestInspector
} from ‘@nestjs/common’;
import {Observable} from ‘rxjs’;
import {map} from ‘rxjs/operators’;
…
export class TransformInterceptor<T> implements NestInterceptor<T, Response<T>> {
intercept(context : ExecutionContext, next : CallHandler<T>) : Observable<Response<T>> {
return next.handle().pipe(map(…));
}
}

There are many more such interceptors in the cats-app however, we picked one for putting the concept in perspective.

You should observe the similarity to the middleware here and the implementation of Chain of Responsibility pattern. It is not very different from the way we used it in middleware. For developers who wondered where are design patterns applied, we already have noticed two places in this framework. Wonder what you will find when you dive deeper inside the framework in the aspect of design pattern? Before we drift further let us pin the rxjs library for a latter edition.

Oh! Before we move to the next element Interceptors are also realization of another design pattern or better call the right term – programming paradigm called Aspect Oriented Programming. More on that in another dispatch.

Pipes

They have close cousin named filters. However, we park filters for a latter edition. Pipes are used to transform the request in a manner which steals the complexity inside the controllers away towards boiler platting code or transformation work. Pipes are the last element before the controller’s business logic is executed. They also serve as guards for the controllers. i.e. they are used for validation. Do not confuse with the Guards you encountered earlier. They are to validate the right to call a route whereas the pipes are to validate the correctness of request in the context of controller’s business. In cats-app you will notice a pipe resembling the code snippet below –

import {
ArgumentMetadata,
BadRequestException,
Injectable,
PipeTransform,
Type
} from ‘@nestjs/common’;
import { plainToClass} from ‘class-transformer’;
import { validate } from ‘class-validator’;
@Injectable
export class ValidationPipe implements PipeTransform<any> {
async transform(value:any, metadata:ArgumentMetadata) {
….
}
private toValidate(metatype: Type<any>):Boolean {
….
}
}

It is worthwhile to notice two foreign libraries which we noticed in the package.json file in an earlier dispatch namely ‘class-transfomer’ and ‘class-validator’. This pipe is dedicated to validating the incoming request.

Controllers

Finally, the business logic which our cool looking Angular UI wanted to invoke is called. There is not much to talk about the controller without the context of the business logic which it implements. For the current dispatch where we are looking at the elements which compose Nestjs, it is worthwhile to give the context of code how these elements tie in together just above controller –

….
@Controller(‘cats’)
@UseGuards(RolesGaurd)
@UseInterceptor(TransformInspector)
export class CatsController {
….
@Post()
@UsePipes(new ValidationPipe())
async create(@Body() createCatDto: CreateCatDto) {
….
}
}

Au revoir!

As we part there are so much of markers we dropped in this fast-paced walk across the cats-app that we will pick them up for a future edition. Only so much can be observed in this edition of ObLog. Till next time – Happy Observing & Coding!!

[1]Read more about it from https://sourcemaking.com/design_patterns/chain_of_responsibility. Sourced on 23-08-2019T21:00.

Contingency Staffing Solutions

Flexible staffing solutions for contract-to-hire and hire-train-deploy models.

RPO & Executive Hiring

Provides specialized end-to-end recruitment outsourcing.

Payroll Rebadging Services

Delivers seamless payroll transition solutions

Managed Services

Ensures specialized end-to-end recruitment outsourcing.

View all at

Our Services