HasabTech

https://www.youtube.com/watch?v=VicWxW0RfT0

How to Create and Use Global Modules in NestJS

hasabTech — Thu, 25 Sep 2025 11:12:20 GMT

Recap from Previous Blog

In our previous blog, we learned that when working inside the CatsModule, if we want to use a provider (dependency) in another module, the standard approach is to export it from cats.module.ts and then import it into the target module. This is the preferred way of reusing dependencies across modules.

However, there’s another way: we can make an entire module a Global Module.

Introducing Global Modules

When you mark a module as global, you don’t have to manually import it into every other module where you want to use its providers. Instead, NestJS automatically makes its services available throughout the application.

To achieve this, you simply:

Import Global from @nestjs/common.
Place @Global() decorator right above the @Module() decorator.

This will make the CatsModule global, so it will now be registered in the global scope. That means we no longer need to import the CatsModule anywhere else. However, one important thing to remember is that whatever dependency you want to share must be explicitly exported, otherwise it won’t be available globally.

Here’s how it looks in code:

import { Global, Module } from '@nestjs/common';
import { CatsService } from './cats.service';
import { CatsController } from './cats.controller';

@Global()
@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService],
})
export class CatsModule {}

Now, let’s move into the RequestModule. Previously, we imported CatsModule manually. But since CatsModule is now global, we don’t need to import it here anymore:

import { Module } from '@nestjs/common';
import { RequestController } from './request.controller';

@Module({
  controllers: [RequestController],
})
export class RequestModule {}

Then in the RequestController, we can directly use the CatsService (from CatsModule) without any errors. If you run the application, you’ll notice everything works fine and we have only one instance of the service shared globally — this is the main benefit of making a module global.

What Happens Without @Global

But let’s say we remove the @Global() decorator. Now the module is no longer global, and if we try to use CatsService in the RequestModule without importing it, we’ll get an error. In that case, we need to import it manually again, just like we learned earlier:

import { Module } from '@nestjs/common';
import { RequestController } from './request.controller';
import { CatsModule } from './cats.module';

@Module({
  controllers: [RequestController],
  imports: [CatsModule],
})
export class RequestModule {}

Conclusion

So the takeaway is: If there’s a dependency you want to use across multiple modules, you can make the module global. But as mentioned earlier, this is not the preferred way. It’s generally better practice to import modules explicitly wherever you need them, to keep your application structure more clear and maintainable.

If you’re a visual learner, check out the following video tutorial for this blog:

https://www.youtube.com/watch?v=D83bP3mfXWE&list=PLgKb0PcT0J0SaWTrS4ZY8ATMaqLeSXgM7&index=11

What is Modules in NestJS

hasabTech — Wed, 24 Sep 2025 18:36:28 GMT

Understanding Modules in NestJS

In this blog, we will discuss an essential concept in NestJS; Modules.

So far, we have been using the main module to register controllers and providers but we have not specifically explored what a module actually is in NestJS.

What is a Module?

A module in NestJS is a class annotated with the @Module() decorator. This decorator accepts an object with four properties:

imports for importing other modules.
exports for exporting providers to other modules.
controllers for declaring route handlers.
providers for declaring the services or providers used in the module.

providers for declaring the services or providers used in the module.

You have likely seen the last two (controllers and providers) used frequently, but the full structure gives us more flexibility and modularity in our application.

When should you create a Module?

You should create a new module when you want to encapsulate a set of closely related features. For example:

A UserModule might contain a UserController and a UserService.

An AlbumModule might contain an AlbumController and an AlbumService.

This structure helps you organise your codebase in a modular and scalable way.

nest generate module users

This command automatically creates a new module file, which you can then connect with the relevant controller and service

Registering Modules

Once you have created multiple feature modules (e.g., UserModule, AlbumModule), you must register them in the imports array of the root module:

@Module({
   @Module({
   imports : [CatsModule, RequestModule, ResponseModule, RedirectModule]})
export class AppModule {}

Creating a Module in NestJS: Example with CatsModule

In our cats folder, we have a file named cats.module.ts. Let’s walk through what we have done here and why it matters.

Step-by-Step Breakdown

First, we import the necessary items from NestJS:

import { Module } from '@nestjs/common';
import { CatsService } from './cats.service';
import { CatsController } from './cats.controller';

Creating and Exporting the Module

Next, we define and export a class named CatsModule

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class CatsModule {}

In NestJS, modules are not shared automatically across the app. If you want to use a provider from one module in another module, you need to:

Export it from the source module.
Import the source module into the destination module.

@Module({
  providers: [CatsService],
  exports: [CatsService], // 👈 This makes it available to other modules
})
export class CatsModule {}

In our CatsModule, we’ve created a service (CatsService) and a controller (CatsController). Here's the basic module structure:

import { Module } from '@nestjs/common';
import { CatsService } from './cats.service';
import { CatsController } from './cats.controller';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class CatsModule {}

Now, if we run the application, you will notice the following:

NestJS first creates an instance of CatsService.

Then it creates an instance of CatsController.

This happens because CatsController depends on CatsService. So NestJS resolves dependencies from the bottom up. If a service depends on another service, that chain is resolved from the lowest level first ensuring everything is ready before the controller is instantiated.

Here’s how we inject the CatsService into the controller:

constructor(private readonly catsService: CatsService) {
  console.log('CatsController instance created');
}

This is standard NestJS Dependency Injection (DI). The framework automatically injects the service instance into the controller.

When you add a service to the providers array of a module, NestJS creates a single instance (singleton) of that service:

This single instance is shared across all controllers in the same module.

That’s the core idea of the singleton pattern one shared instance per provider per module.

So, even if multiple controllers depend on CatsService, they will all receive the same instance.

Now, let’s say you try to use CatsService in another controller (e.g., in a RequestController inside RequestModule) like this:

constructor(private readonly catsService: CatsService) {}

If you run the application without importing CatsModule, you’ll get an error like:
Nest can't resolve dependencies of the RequestController (...) CatsService at index [0]

This means that CatsService is not available in the context of RequestModule.
NestJS modules are self contained by default. The scope of a provider is limited to the module where it is declared, unless you explicitly export it.

To fix the above error follow these steps:

Step 1: Export the Service from CatsModule:

@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService], // 👈 This allows other modules to use it
})
export class CatsModule {}

Step 2: Import CatsModule into RequestModule:

import { Module } from '@nestjs/common';
import { RequestController } from './request.controller';
import { CatsModule } from 'src/cats/cats.module';

@Module({
  controllers: [RequestController],
  imports: [CatsModule], // 👈 Import the whole module, not just the service
})
export class RequestModule {}

Now NestJS can resolve the dependency, and CatsService will be available in RequestController.

NestJS resolves dependencies from bottom to top resolving providers before controllers.

Providers in NestJS are singleton by default shared within the module.

A provider’s scope is limited to its module unless it is exported.

To use a provider in another module:

Export it from the source module.
Import the entire module (not just the provider) into the destination module.

This behaviour makes modules self-contained and reusable.

Wrapping Up

We now understand how modules encapsulate their providers and controllers, how singleton services work, and how to properly share services between modules using exports and imports. In the future blog, we’ll explore custom provider scopes like Request, Transient, and how to build global modules.

If you’re a visual learner, check out the following video tutorial for this blog:

https://www.youtube.com/watch?v=U0LGQjxyuw8

What is Inversion Of Control?

hasabTech — Tue, 23 Sep 2025 14:26:03 GMT

Introduction

In our previous blog we explored in detail how to implement Dependency Injection and understood its role in creating loosely coupled and more maintainable code. As we discovered there are multiple ways to implement Dependency Injection, something we will delve into in future blogs.

In this blog, our focus shifts to a closely related but often misunderstood concept: “Inversion of Control”.

What is Inversion of Control?

Inversion of Control is a design principle, not a design pattern and this distinction is crucial. While the terms are sometimes used interchangeably they represent different aspects of software design.
In traditional programming, your classes or modules are in charge of creating and managing their own dependencies. However with Inversion of control is inverted an external entity, such as a framework or container takes over the responsibility of providing those dependencies. This shift of responsibility leads to better code reusability, testing, and decoupling.

Design Principles vs. Design Patterns

Let’s pause for a moment to clear up a common confusion: the difference between design principles and design patterns.

A design principle is a high-level guideline or best practice that helps developers design robust software systems. It is conceptual and theoretical, focusing on how to approach a problem.

A design pattern, on the other hand, is a low-level, practical solution to a recurring programming problem. It provides a specific structure or template that you can use to solve implementation challenges.

In simpler terms:

Design principles guide how to think, while design patterns show how to build.

A real life example

To understand the concept of dependency, let’s consider a few simple real-world examples.

In everyday language, the word "dependency" means something you rely on. For instance, you depend on your laptop to do your work — this makes the laptop your dependency.

Now let’s take the example of a car. A car depends on many components to function — such as an engine, wheels, doors, windows, and more. Among them, the engine is a crucial part. So, we can say:

The engine is a dependency of the car.

In object-oriented programming, if you're building a Car class, you’ll need to create objects for each of these components. That means you are manually managing the dependencies inside your class. This tight coupling makes your code complex and harder to modify.

For example, if you want to:

change the engine type
update the tire size,
adjust the window color,
replace the car's color

you’d need to modify the Car class directly. This results in a tightly coupled system where every small change requires direct modifications violating good software design practices.

The goal in modern software engineering is to build loosely coupled systems and that’s where the concept of Inversion of Control comes in.

In the traditional approach, the code controls the creation of dependencies, but Inversion of Control shifts this responsibility away from your class and hands it over to an external entity in our case, the NestJS framework.

So instead of manually creating and managing all the dependencies inside the Car class (or any other class), you delegate that control to the framework.

This concept of transferring control of dependency management from your code to the framework is called Inversion of Control, and in NestJS, it is achieved through Dependency Injection.

Applying Inversion of Control in NestJS (with Dependency Injection)

Let’s look at how NestJS handles Inversion of Control using Dependency Injection with a simple example.
CatsController

import { injectable } from '@nestjs/common';

@injectable()
import class CatService {
    private readonly cats: string [] = []; 

    create(cat:string) {
        this.cats.push.(cat);
    }
    findAll() : string [] {
        return this.cats;
    }
}

Here we define a CatsService and mark it with the @Injectable() decorator. This tells NestJS that this service can be injected as a dependency into other components like controllers.


import { Controller, Post, Body, Get, } from '@nestjs/common';
import { CatsService } from './cats.service';

@Controller('cats')
export class CatsController {
    constructor (private readonly catsService: CatsService) }


@Post()
async create (@Body() cat:any){
    console.log('cat', cat);
    this.catsService.create(cat);
}
@Get()
async findAll() : Promise{
    return this.catsService.findAll();
}

In the controller, we inject the CatsService through the constructor. This is a clear example of Dependency Injection rather than creating a new instance of the service manually, NestJS provides it automatically.

By using the @Injectable() and constructor pattern, NestJS manages the lifecycle and creation of the CatsService for us.

This is a real world example of Inversion of Control we are no longer manually controlling how the service is created or used. Instead, NestJS takes over that control.

This makes our code more modular, testable, and maintainable.

Registering Dependencies in the Module

In NestJS, you cannot inject a class (like a service) into a controller unless it’s registered as a provider within a module. This registration allows NestJS to manage the class through its Inversion of Control (IoC) container.

Let’s look at the module definition:

@Module({
    controllers : [CatsController],
    provider : [CatsService],
})
export class AppModule {}

In the AppModule, we list CatsService under the providers array.

By doing this, we are telling NestJS to create and manage the instance of CatsService within its IoC container.

Once registered, CatsService becomes available for injection into other parts of the application like the CatsController.

Conclusion

In this blog, we explored the concept of Inversion of Control (IoC) and how it's implemented in NestJS using Dependency Injection (DI).

We began by understanding what dependency means using simple real-life examples and explained how managing dependencies manually can lead to tightly coupled and hard-to-maintain code.

Inversion of Control helps solve this by shifting the responsibility of dependency management from your code to the framework. In NestJS, this is achieved through Dependency Injection, a design pattern that allows the framework to supply required services (or other dependencies) into your components.

We also learned that in order to inject any service into a controller, it must first be registered as a provider in a module. Once registered, NestJS uses its built-in IoC container to create and manage instances of that service behind the scenes.

If you’re a visual learner, check out the following video tutorial for this blog:

https://www.youtube.com/watch?v=ZCbGVoqAEX0

How Dependency Injection Works in NestJS

hasabTech — Mon, 22 Sep 2025 13:37:25 GMT

Introduction

In our previous blog we explored specific library responses in NestJS. Now it’s time to dive into one of the framework’s most powerful and core concepts: Providers specifically Services.

Understanding Dependency Injection

Before we go deeper into how services work, let’s first understand a foundational concept behind them Dependency Injection.
As the name suggests, Dependency Injection refers to the process of providing (or injecting) dependencies into a class rather than creating them manually. In NestJS, this pattern allows us to inject services into controllers.
Let’s consider a simple example: a Car and an Engine. The Car depends on the Engine to work.

class Engine {
    constructor(type) {
        this.type = type;
    }

    start() {
        return `The ${this.type} engine is starting...`;
    }
}

class Car {
    constructor() {
        this.engine = new Engine('V8'); // tightly coupled
    }

    startEngine() {
        return this.engine.start();
    }
}

In the non-dependency injection example, the Car class creates its own Engine, which means it is tightly coupled to a specific engine type. This tight connection makes your code rigid if you want to change the Engine class, you will likely need to update the Car class as well.
With Dependency Injection, we solve this problem by injecting the dependency (e.g., Engine or a service) from the outside, rather than creating it inside the class. This allows your classes (like controllers) to remain loosely coupled with the services they use.

Making a Class Injectable

In order to make a class injectable, we use the @Injectable() decorator provided by the NestJS framework. This tells NestJS that the class can be managed by its Dependency Injection system.

Here’s an example using a simple service class called CatService. This service manages a list of cat names. We declare a private and readonly cats array to store string values. Then we define two methods:

create() to add a single cat name to the array.

findAll() to return the complete list of cat names.

import { injectable } from '@nestjs/common';

@injectable()
import class CatService {
    private readonly cats: string [] = []; 

    create(cat:string) {
        this.cats.push.(cat);
    }
    findAll() : string [] {
        return this.cats;
    }
}

Now that we have defined our CatService, let's inject it into a controller so we can use its methods to handle incoming HTTP requests.

To do this, we follow three simple steps:

Import the service.

Import the service.
Decorate the controller with @Controller().
Inject the service via the constructor using NestJS Dependency Injection system.

import { Controller, Post, Body } from '@nestjs/common';
import { CatsService } from './cats.service';

@Controller('cats')
import class CatsController {
    constructor (private readonly catsService: CatsService) }

After creating the service, we now use it inside our controller to handle incoming POST requests. Here’s how we define the method:

@Post()
async create (@Body() cat:any){
    this.catsService.create(cat);
}
}

@Post() is a route handler decorator, It tells NestJS that the following method should handle HTTP POST requests.
@Body() is a parameter decorator, It tells NestJS to extract the data from the body of the incoming request.

To verify that we’re correctly receiving the data in our controller, let’s add a simple log inside our create() method:

@Post()
async create (@Body() cat:any){
    console.log('cat', cat);
    this.catsService.create(cat);
}

Now, when you send a POST request via Postman (e.g., to http://localhost:3000/cats), you should see the request body logged in your terminal. If you encounter an error like this when running your app:

Nest can't resolve dependencies of the CatsController (?). Please make sure that the argument CatsService at index [0] is available in the AppModule context.

Here’s how to fix it...

In NestJS, you can not simply create a service and expect it to work automatically even if you have imported it.
For a service to be usable, you must explicitly register it as a provider in the relevant module — usually in AppModule.

Let’s take a look at how to do that.

In your app.module.ts file, add your controller and service like this

controllers : [
    CatsController,
    RequestController,
    ResponseController,
    RedirectController,

],
providers: [CatsService]
})
export class AppModule {}

NestJS uses Dependency Injection and needs to know which services are available in the current module. Remember, services and controllers are just regular TypeScript classes what makes them behave differently is the decorator you apply @Injectable() for services and @Controller() for controllers. Decorators add the necessary metadata to tell NestJS how to use these classes.

So once your service is created, injected, and registered as a provider, you will be able to send a POST request from Postman to your controller and see it working with the request body successfully logged and handled. In future blogs we will explore how to organize services and controllers using separate modules making your application more scalable and maintainable.

Conclusion

we explored how Dependency Injection works in NestJS, focusing specifically on how to inject a Service (Provider) into a Controller. We learned how @Injectable() and @Controller() decorators help NestJS recognize and manage these classes, and how important it is to register services in the module's providers array to avoid dependency resolution errors. This structure enables loosely coupled, maintainable, and testable code which is one of the major strengths of the NestJS framework.

If you’re a visual learner, check out the following video tutorial for this blog:

Follow us for more such content:

https://www.youtube.com/watch?v=yX0di9NBfdg

How to Handle Custom Responses and Headers in NestJS with @Res

hasabTech — Tue, 26 Aug 2025 14:00:00 GMT

In the previous blog, we discussed how to modify HTTP status codes and headers while sending responses to the client. In this post, we'll explore another approach: Modifying headers manually in a NestJS controller using @Res() — similar to how it's done in Express.js.

Express vs. NestJS Response Flow

NestJS, by default, handles HTTP responses for you. This means you can simply return a value from your controller, and Nest will convert it into a response, but sometimes, you might want fine-grained control, like setting custom headers or using an existing Express-style library. In such cases, you can manually handle the response.

How to Modify Headers with @Res( )

We already learned how to intercept Express request in our controller so we imported a request like

import {Controller, Get, HttpCode, HttpStatus, Header, Request}from '@nestjs/common';

we can also import a response here like with full form Request or short form Res

import {Controller, Get, HttpCode, HttpStatus, Header, Res}from '@nestjs/common';

Similarly we also import types for this particular Response from Express

import {Response} from 'express';

Now Create a @Get Request

Get()   
FindAll(@Res() response: Response) {
Response.status(HttpStatus.OK) .send();
}

Understanding @Res, res, and Response

In this code

import {Controller, Get, HttpStatus, Res} from "@nestjs/common";
import { Response } from "express";

@Controller("response")
export class ResponseController {
  @Get()
  findAll(@Res() res: Response) {
    res.status(HttpStatus.OK).send();
  }
}

@Res() → Decorator to inject the response object
response → A custom variable name (can also be res)
Response → Type from express for better IntelliSense and typing

So finally, we can modify our header manually and send response to our client.

Conclusion

While NestJS encourages using its built-in response handling, the @Res decorator lets you leverage Express-style syntax for fine-grained control. Use this sparingly to avoid losing Nest’s powerful features.

Note: Use manual response handling sparingly, as it bypasses features like interceptors, exception filters, and built-in decorator.

If you’re a visual learner, check out the following video tutorial for this blog:

Follow us for more such content:

https://www.youtube.com/watch?v=v7e59lQKz6U

Understanding HTTP Status Codes and Headers in NestJS

hasabTech — Sat, 23 Aug 2025 13:19:42 GMT

When building APIs with NestJS, one of the crucial aspects is handling HTTP status codes and headers in your responses.

These elements provide valuable information to clients about the outcome of their requests and help shape the behavior of the communication between the server and the client.

HTTP Status Codes

HTTP status codes are three-digit numbers returned by the server to indicate the status of the request made by the client. NestJS makes it straightforward to set these codes in your API responses.

Setting HTTP Status Codes

In NestJS, you can set the HTTP status code using the @HttpCode decorator or by directly chaining it with the response. Let's look at an example:

Create a new controller. I created one with the name of response with the help of this:

nest g controller response

import { Controller, Get, HttpCode } from '@nestjs/common';

@Controller('response')
export class ResponseController {
  @Get()
  @HttpCode(201)
  findAll() {
    return 'Shameel is testing 201 response with GET request.';
  }
}

By default, a GET request is sent with a 200 status code.
In this example, the @HttpCode(201) decorator explicitly sets the HTTP status code to 201 OK.

When you test it with POSTMAN (or any other tool), you should be able to verify it.

Common HTTP Status Codes

Here are a few common HTTP status codes and their meanings:

200 OK: The request was successful.
201 Created: The request was successful, and a new resource was created.
400 Bad Request: The server could not understand the request.
404 Not Found: The requested resource could not be found.

Ensure to choose the appropriate status code based on the semantics of your API.

Using HttpStatus Enum

HttpStatus is an Enum in which you can use proper string names; this way, you won't have to memorize status codes for the particular type of action that you are going to do.

All you have to do is import HttpStatus from @nestjs/common and then use it like this:

If you hover over CREATED then you can see its actual value. That should be the case with any of the Enum and its string you use in TypeScript.

Code Snippet:

import { Controller, Get, HttpCode, HttpStatus } from '@nestjs/common';

@Controller('response')
export class ResponseController {
  @Get()
  @HttpCode(HttpStatus.CREATED)
  findAll() {
    return 'Shameel is testing 201 response with GET request.';
  }
}

HTTP Headers

HTTP headers provide additional information about the server's response or the request being made. NestJS allows you to work with headers easily.

Setting HTTP Headers

To set HTTP headers in NestJS, you can use the @Header decorator or directly set them using the response object. Here's an example:

import { Controller, Get, Header, Res } from '@nestjs/common';

@Controller('example')
export class ExampleController {
  @Get()
  @Header('Cache-Control', 'no-cache') // Set header using @Header decorator
  findAll(@Res() response): string {
    return 'This is the response body';
  }
}

In this example, the @Header('Cache-Control', 'no-cache') decorator sets the Cache-Control header to 'no-cache'.

Common HTTP Headers

Content-Type: Specifies the media type of the resource.
Cache-Control: Directs caching mechanisms in both requests and responses.
Authorization: Contains credentials for authenticating the client with the server.

Below is the code of a POST request handler:

  @Post()
  @Header('Cache-Control', 'none')
  @Header('X-My-Header', 'Shameel')
  create() {
    return 'Shameel is POST request with additional headers.';
  }

You can try it with POSTMAN like this:

Conclusion

Understanding and effectively using HTTP status codes and headers in your NestJS application is crucial for building robust and reliable APIs. Whether you're indicating the success of a request or controlling caching behaviour, mastering these concepts will enhance the communication between your server and clients.

Remember to refer to the official NestJS documentation for more in-depth information and advanced use cases.

If you’re a visual learner, check out the following video tutorial for this blog:

Follow us for more such content:

https://www.youtube.com/watch?v=lmp0mkOb6bo&t=13s

Redirection in NestJS

hasabTech — Thu, 21 Aug 2025 17:23:13 GMT

Understanding HTTP Redirection: A Brief Overview

HTTP redirection is a mechanism used by web servers to instruct browsers to navigate from one URL to another. This process is crucial for various scenarios, such as when a page has permanently moved or when a temporary redirect is needed. Two common status codes used for redirection are 301 (Moved Permanently) and 302 (Found or Moved Temporarily).

301 (Moved Permanently):

A 301 status code indicates that the requested resource has been permanently moved to a new location.
Browsers and search engines interpret this as a permanent change, and they update their records accordingly.
This is useful when you want to divert your traffic to your new URL.

302 (Found or Moved Temporarily):

A 302 status code indicates that the requested resource has been temporarily moved to a different location.
Browsers understand this as a temporary redirection and may continue to use the original URL for future requests.
This is beneficial when you need a temporary redirect, such as during maintenance or when testing a new page.

Implementing Redirection in NestJS

Now, let's delve into the provided NestJS code that demonstrates how to implement redirection using these HTTP status codes.

Since you are following a series, your NestJS project should be up and running.

Create a new controller by the name of redirect:

nest g controller redirect

Paste the following code in src/redirect.

import { Controller, Get, Redirect } from '@nestjs/common';

@Controller('redirect')
export class RedirectController {
  @Get('youtube')
  @Redirect('https://www.youtube.com/@hasabTech', 301) //permenant
  redirectToNewUrl301() {
    console.log('Permenant!');
  }

  @Get('github')
  @Redirect('https://github.com/hasabTech', 302) //temporary
  redirectToTemporaryUrl302() {
    console.log('Temporary!');
  }
}

Code Explanation:

Decorator Usage:

The @Controller decorator is used to define a controller for handling HTTP requests related to redirection.
The @Get decorator specifies that the following method should handle GET requests for the specified route.

Redirection Implementation:

The @Redirect decorator is employed to specify the target URL and the HTTP status code for redirection.
In the redirectToNewUrl301 method, a 301 status code is used for a permanent redirect to the YouTube channel.
In the redirectToTemporaryUrl302 method, a 302 status code is used for a temporary redirect to the GitHub profile.

Code Execution:

It's important to note that the code block following the redirection decorator (return { url: 'https://www.google.com/' };) will be executed in 302 but not in 301.

Execution

When you hit in browser:

localhost:3000/redirect/youtube

You will be navigated to our YouTube channel.

But, when you hit this in browser:

localhost:3000/redirect/github

Then, you would rather be re-directed to the Google page. This is because in 302, the method below @Redirect() is executed, so make sure that you early return it in case the method has some code which is under development so that the users can successfully (temporarily) be navigated to the updated URL.

Update it like this:

@Get('github')
  @Redirect('https://github.com/hasabTech', 302) //temporary
  redirectToTemporaryUrl302() {
  return
    //This will be executed!
    return { url: 'https://www.google.com/' };
  }

By understanding HTTP redirection and reviewing this NestJS code, developers can effectively manage URL transitions, ensuring a smooth user experience and proper handling of changes in website structure.

If you’re a visual learner, check out the following video tutorial for this blog:

Follow us for more such content:

https://www.youtube.com/watch?v=0EuhRfJn0Aw&embeds_referring_euri=https%3A%2F%2Fdev.to%2F&source_ve_path=MjM4NTE

NestJS Request | Param, Body, Query, Headers, IP

hasabTech — Sat, 16 Aug 2025 12:05:42 GMT

In NestJS, decorators are used to define metadata for various aspects of your application, including request handling. Let's break down each of the decorators for handling a NestJS Request.

1. `@Param(key?: string)`

Description: This decorator is used to extract parameters from the request URL.
- Usage: It can be applied to method parameters in a controller class to capture specific parameters from the URL.
  
  Example:

 @Get('/param/:id')
  getParam(@Param('id') id: string) {
    return `Param ID: ${id}`;
  }

In this example, the :id in the route will be captured and passed to the getParam method.

2. `@Body(key?: string)`

Description: Used to extract data from the request body.
- Usage: Apply it to a method parameter to receive data from the body of a POST or PUT request.
  
  Example:

   @Post()
  postBody(@Body() body: any) {
    return `Body Data: ${JSON.stringify(body)}`;
  }

This example expects a JSON object with a key data in the request body.

3. `@Query(key?: string)`

Description: Extracts parameters from the query string in the URL.
Usage: Apply it to a method parameter to capture query parameters.

Example:

  @Get()
  getQuery(@Query() query: any) {
    return `Query Parameter:${JSON.stringify(query)}`;
  }

If the URL is /example?name=hasabTech, the getQuery method will receive {name=:hasabTech}

4. `@Headers(name?: string)`

Description: Extracts values from the request headers.

Usage: Apply it to a method parameter to get a specific header value.

Example:

    @Get('/header/')
    getHeaders(@Headers() headers: any) {
      return `Header: ${JSON.stringify(headers)}`;
    }

This example extracts the value of the authorization header.

5. `@Ip()`

Description: Retrieves the client's IP address from the request.
Usage: Apply it to a method parameter to get the client's IP.

Example:
```
   @Get('ip')
    getIp(@Ip() ip: string) {
      return `Client IP: ${ip}`;
    }
```
This example retrieves the IP address of the client making the request.

Complete Controller Code

import {
  Body,
  Controller,
  Get,
  Ip,
  Param,
  Post,
  Query,
  Headers,
} from '@nestjs/common';

@Controller('request')
export class RequestController {
  @Get('/param/:id')
  getParam(@Param('id') id: string) {
    return `Param ID: ${id}`;
  }

  @Post()
  postBody(@Body() body: any) {
    return `Body Data: ${JSON.stringify(body)}`;
  }

  @Get()
  getQuery(@Query() query: any) {
    return `Query Parameter:${JSON.stringify(query)}`;
  }

  @Get('/header/')
  getHeaders(@Headers() headers: any) {
    return `Header: ${JSON.stringify(headers)}`;
  }

  @Get('ip')
  getIp(@Ip() ip: string) {
    return `Client IP: ${ip}`;
  }
}

These decorators simplify the process of handling different parts of the HTTP request in your NestJS application by providing a clean and structured way to access request parameters, body, headers, IP address, and host parameters.

If you’re a visual learner, check out the following video tutorial for this blog:

Follow us for more such content:

https://www.youtube.com/watch?v=-7oCm3I0544

NestJS Nested Routing, Wildcard, Request

hasabTech — Thu, 14 Aug 2025 22:44:47 GMT

In previous blog, we talked about about NestJS controllers and now we will be exploring a bit about nested routing, wildcard and starting with NestJS request.

NestJS Nested Routing: A Modular Approach

NestJS encourages a modular and organised structure for building applications. One key aspect is nested routing, where routes are organised hierarchically, mirroring the structure of your application. This approach provides clarity and maintainability, making it easier to manage the complexity of larger applications.

This is a simple NestJS controller:

import { Controller, Get, Param, Post } from '@nestjs/common';

@Controller('cats')
export class CatsController {
@Get()
  findAll(): string {
    return 'This action returns all cats of hasabTech!';
  }
}

If you send GET request to /cats/ then it will return 'This action returns all cats of hasabTech!'.

In order to make nested routes within this controller for GET request handler for this case, all you have to make changes is in @Get() decorator to something like this:

@Get('/hasabTech/123')

Now you can access this route with this:

/cats/hasabTech/123

Wildcard Routes

Wildcard routes in NestJS provide a way to capture dynamic or unpredictable segments in a URL, enabling the handling of various scenarios within a single route.

You can make changes like this:

@Get('/hasab*ech/')

Now you can access it with any character between "hasab" and "ech". For example:

/cats/hasabTech
/cats/hasabMech
/cats/hasabRech

NestJS Request

In NestJS, the @Req() decorator is used to access the underlying Express.js request object. This decorator allows developers to tap into the details of an incoming HTTP request, gaining access to headers, parameters, and other request-specific information.

For better typing in TypeScript, please install this as dev dependency:

npm install @types/express --save-dev

Now you need to replace the controller code with this:

import { Controller, Get, Req } from '@nestjs/common';
import { Request } from 'express';

@Controller('cats')
export class CatsController {
  @Get()
  findAll(@Req() req: Request): string {
    console.log(req);
    return 'This action returns all cats of hasabTech!';
  }
}

As you can see that we have added @Req as a decorator and when you check your terminal after hitting /cats/, then you will observe request object similar to Express.js.

If you’re a visual learner, check out the following video tutorial for this blog:

Follow us for more such content:

https://www.youtube.com/watch?v=zy3wtZVe0so&embeds_referring_euri=https%3A%2F%2Fdev.to%2F&source_ve_path=MjM4NTE

NestJS Controllers

hasabTech — Thu, 14 Aug 2025 11:45:25 GMT

NestJS, a progressive Node.js framework, has gained popularity for its modular and scalable architecture. One of its key components is the Controller, which plays a pivotal role in handling incoming requests and defining the application's routing logic. In this blog post, we will dive into the NestJS Controller and explore its routing mechanism with practical coding examples.

Understanding NestJS Controllers

Controllers in NestJS are responsible for handling incoming HTTP requests, processing them, and returning an appropriate response. They act as the bridge between the client (request) and the server (application logic). Controllers are decorated with the @Controller decorator, and they contain methods that handle specific routes.

Let's create a simple NestJS controller to illustrate the basic structure:


import { Controller, Get } from '@nestjs/common';

@Controller('cats')
export class CatsController {
  @Get()
  findAll(): string {
    return 'This action returns all cats';
  }
}

In this example, we've created a CatsController decorated with @Controller('cats'). The argument passed to @Controller specifies the base route for all the methods within this controller. The @Get() decorator is used to define an HTTP GET route, and the findAll method is the handler for this route.

Routing in NestJS

NestJS follows a decorator-based approach for defining routes within controllers. Decorators are special functions prefixed with @ that provide metadata to NestJS, allowing it to understand the structure of the application.

Let's extend our CatsController to include more routes and demonstrate different HTTP methods:

// cats.controller.ts

import { Controller, Get, Post, Put, Delete } from '@nestjs/common';

@Controller('cats')
export class CatsController {
  @Get()
  findAll(): string {
    return 'This action returns all cats';
  }

  @Get(':id')
  findOne(@Param('id') id: string): string {
    return `This action returns cat #${id}`;
  }

  @Post()
  create(): string {
    return 'This action creates a new cat';
  }

  @Put(':id')
  update(@Param('id') id: string): string {
    return `This action updates cat #${id}`;
  }

  @Delete(':id')
  remove(@Param('id') id: string): string {
    return `This action removes cat #${id}`;
  }
}

In this extended example, we've added methods for handling GET, POST, PUT, and DELETE requests. The @Get(':id') decorator defines a route with a dynamic parameter (id), and the @Param('id') decorator extracts that parameter from the request.

Organizing Controllers in Modules

NestJS encourages the use of modules to organize the application. Controllers are often associated with modules, and the @Module decorator is used for this purpose. Here's an example of how you might organize your controllers into a module:

// cats.module.ts

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';

@Module({
  controllers: [CatsController],
})
export class CatsModule {}

Conclusion

NestJS controllers and routing mechanisms simplify the process of handling HTTP requests in your application. By using decorators, you can easily define routes and extract parameters from incoming requests. This modular and expressive approach contributes to the overall readability and maintainability of your code.

Remember, this is just a basic overview, and NestJS offers many more features for handling authentication, validation, and other aspects of web development.

If you’re a visual learner, check out the following video tutorial for this blog:

Follow us for more such content:

https://www.youtube.com/watch?v=3q06vqkSI_A&list=PLgKb0PcT0J0SaWTrS4ZY8ATMaqLeSXgM7&index=2

Understanding Default NestJS Project Structure

hasabTech — Thu, 07 Aug 2025 12:01:38 GMT

In previous blog, we understood the use-cases for Node.js, Express.js and NestJS and then learned how to install NestJS CLI and initiated our project.

In this blog, we will understand default NestJS project structure.

We will not be diving deep into any of the configuration files; rather, we'd discuss core files which we will be using for our NestJS series.

Starting the project

In package.json file, you can find these two:

"start": "nest start",
"start:dev": "nest start --watch",

If you use npm run start then whenever you make changes, you will have to restart your server. So, during development mode, always run this: npm run start:dev so that as soon as you make any changes in the file, the server restarts automatically.

Nest.js Default Core Files

When diving into a NestJS project, the src/ directory plays host to several essential files. Let's take a closer look at each one:

main.ts:

As the gateway to your application, main.ts is where the NestJS application instance comes to life and is registered to a specific port (i.e., 3000 by default), enabling access from your client apps:

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
}
bootstrap();

app.module.ts:

This file takes center stage as the root module for your application. Every other module you create will find its registration within this file:

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';

@Module({
  imports: [],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

app.controller.ts:

This file serves as the foundation for your controllers, featuring a basic controller class with a single route definition.

import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get()
  getHello(): string {
    return this.appService.getHello();
  }
}

app.controller.spec.ts:

This is the unit test file designed for the app.controller.ts class. It ensures the reliability of your controller through testing. Here's a snippet illustrating a basic test:

import { Test, TestingModule } from '@nestjs/testing';
import { AppController } from './app.controller';
import { AppService } from './app.service';

describe('AppController', () => {
  let appController: AppController;

  beforeEach(async () => {
    const app: TestingModule = await Test.createTestingModule({
      controllers: [AppController],
      providers: [AppService],
    }).compile();

    appController = app.get(AppController);
  });

  describe('root', () => {
    it('should return "Hello World!"', () => {
      expect(appController.getHello()).toBe('Hello World!');
    });
  });
});

app.service.ts:

Here, you'll encounter a fundamental service responsible for executing logic utilized by your controller:

import { Injectable } from '@nestjs/common';

@Injectable()
export class AppService {
  getHello(): string {
    return 'Hello Shameel!';
  }
}

Understanding the purpose of each core file empowers you to navigate and structure your NestJS project effectively.

If you’re a visual learner, check out the following video tutorial for this blog:

Follow us for more such content:

https://www.youtube.com/watch?v=l2W2FxK0WjU&t=1s

Getting Started With NestJS

hasabTech — Tue, 05 Aug 2025 18:33:12 GMT

Introduction

Hello everyone, we are starting a series where we will be learning about NestJS as a framework, understanding fundamental concepts and getting down to its depth.

Node.js → Express.js → NestJS

Lets discover how we arrived at NestJS.

The arrival of NestJS by no means makes Node.js or Express.js obsolete.

Node.js in itself can be used in variety of applications like scripting, automation and stuff, while Express.js is also being utilized substantially in industry, on top of which great applications have been built and are currently in use.

Node.js

Initially, JavaScript used to execute only in Web Browser.

Node.js came with a BANG and allowed JavaScript to be written and executed on the server.

Note: Node.js is not a library or framework of JavaScript but it's a Runtime Environment.

However, in Node.js, we had to write a lot of code for a server to make simple CRUD applications.

Thus came: Express.js!

Express.js

It is an unopinionated, minimalist framework built on top of Node.js

It solved extra over-code which we used to do it in Node.js. However, it's unopinionated, meaning anyone can create and use their own structure however they wish. It doesn’t enforce any strict conventions —developers are free to do whatever they want, in whatever way they prefer. No specific design pattern is enforced. It's essentially a 'do as you like' approach.

Next came: NestJS!

NestJS

NestJS uses Express.js as underlying technology which is built on top of Node.js.

It provides a proper structure for development, with implied design patterns and a standardized modular approach for using Controllers and Services. You have to follow a global standard to make things work.

Note: NestJS also allows you to use Fastify as underlying tech if you don't want to use Express.js.

Problems tackled in each of these

Each of these frameworks solved their own problems. Node.js allowed JavaScript to be written on server. Express.js removed extra code which we used to write in Node.js and allowed ease in development and NestJS restricted developers to use good coding practices.

Prerequisite

You should have knowledge of the following before moving forward with our the NestJS series:

JavaScript
TypeScript
Node.js
Client-Server Architecture
Express.js (at least a basic understanding)

Installing Nest.js

You should have Node.js installed. You can verify it by running the following command in CMD:

node -v

Open command prompt in Administrative mode and run this:

npm i -g @nestjs/cli

This will install NestJS globally in your system.

Creating our first NestJS Project

After installing NestJS, you can create scaffold a project with the following:

nest new

For example:

nest new shameel-project

You will be provided with these three package managers:

npm
yarn
pnpm

I proceeded with npm. After waiting for a minute, your first NestJS project will be created.

What's Next?

Next, we will be exploring and understanding the folder structure and what each file means which have been created by default from executing the above command.

Stay tuned! =)

If you’re a visual learner, check out the following video tutorial for this blog:

Follow us for more such content: