DEV Community: amir fakoor

✨ Build a Better Axios Client in NestJS

amir fakoor — Mon, 26 May 2025 10:17:07 +0000

When building back-end services with NestJS, making reliable and observable HTTP requests is crucial, especially when dealing with third-party APIs or microservice communication.

In this article, we’ll create a reusable AdvancedAxiosService that wraps Axios with:

Request timing
Retry capabilities
Logging for success, retry, and failure scenarios

Let's get started. 💡

🎯 Why Use a Custom Axios Service?

Axios is a powerful HTTP client, but out of the box, it lacks advanced features like:

Built-in retries for failed requests
Logging request metadata such as latency
Unified interface for all request types

With NestJS, we can wrap Axios into a service that includes all of these features and inject it wherever we need.

📦 Install Dependencies

We’ll use axios-retry, a lightweight library that automatically retries failed Axios requests with customizable logic.

Before diving into the code, make sure you have axios and axios-retry installed in your project:

npm install axios axios-retry

Or with yarn:

yarn add axios axios-retry

🛠️ The Service Implementation

In this section, we’re creating a custom injectable service in NestJS that wraps the Axios HTTP client with enhanced functionality. This includes automatic retries for failed requests using axios-retry, and detailed logging for request duration and outcomes.

import { Injectable, Logger } from '@nestjs/common'
import axios, { AxiosInstance, AxiosRequestConfig, AxiosResponse } from 'axios'
import axiosRetry from 'axios-retry'

@Injectable()
export class AdvancedAxiosService {
  private readonly axiosInstance: AxiosInstance
  private readonly logger = new Logger(AdvancedAxiosService.name)

  constructor() {
    this.axiosInstance = axios.create()

    // Track request start time
    this.axiosInstance.interceptors.request.use((config) => {
      ;(config as any).metadata = { startTime: new Date() }
      return config
    })

    // Setup retry logic, see more details of options: https://github.com/softonic/axios-retry?tab=readme-ov-file#options.
    axiosRetry(this.axiosInstance, {
      retries: 3,
      retryDelay: (retryCount) => retryCount * 1500,
      shouldResetTimeout: true,
      retryCondition: () => true,
      onRetry: (retryCount, error, requestConfig) => {
        const metadata = (requestConfig as any).metadata
        const duration = new Date().getTime() - metadata.startTime.getTime()
        this.logger.warn(
          `Retry #${retryCount} for request to ${requestConfig.url} failed. Error: ${error.message}. Duration: ${duration}ms`,
        )
      },
    })

    // Log response duration
    this.axiosInstance.interceptors.response.use(
      (response: AxiosResponse) => {
        const metadata = (response.config as any).metadata
        const duration = new Date().getTime() - metadata.startTime.getTime()
        this.logger.log(
          `Successful ${response.config.method?.toUpperCase()} request to ${response.config.url}. Status: ${
            response.status
          }. Duration: ${duration}ms`,
        )
        return response
      },
      (error) => {
        const metadata = (error.config as any)?.metadata
        if (metadata) {
          const duration = new Date().getTime() - metadata.startTime.getTime()
          this.logger.error(
            `Failed ${error.config.method?.toUpperCase()} request to ${error.config.url}. Error: ${
              error.message
            }. Duration: ${duration}ms`,
          )
        }
        return Promise.reject(error)
      },
    )
  }

  async request<T = any>(config: AxiosRequestConfig): Promise<T> {
    const response = await this.axiosInstance.request<T>(config)
    return response.data
  }

  async get<T = any>(url: string, config?: AxiosRequestConfig): Promise<T> {
    return this.request<T>({ ...config, method: 'GET', url })
  }

  async post<T = any>(url: string, data?: any, config?: AxiosRequestConfig): Promise<T> {
    return this.request<T>({ ...config, method: 'POST', url, data })
  }
}

Here’s a breakdown of what we’re adding:

Axios instance creation: Instead of using Axios globally, we create an isolated instance so we can apply custom configuration and interceptors without side effects.
Request interceptor: Captures the start time of each request, so we can later calculate how long it took to complete (latency).
Retry configuration: Automatically retries failed requests up to 3 times with a 1.5-second incremental delay between each attempt. This is useful for handling temporary network issues or rate limits.
Response interceptor: Logs successful responses with method, URL, status code, and latency.
Error handler: Logs failed requests with relevant metadata, including error messages and how long the failed attempt took.
Helper methods (get, post, request): These wrap Axios request methods and return only the response data for cleaner usage.

This service is designed to be reusable across your project, giving you consistency and better observability for all outbound HTTP calls.

🧪 How to Use It

@Module({
  providers: [AdvancedAxiosService],
  exports: [AdvancedAxiosService],
})
export class HttpClientModule {}

2. Inject and use it in your services:

@Injectable()
export class ExampleService {
  constructor(private readonly http: AdvancedAxiosService) {}

  async fetchData() {
    const data = await this.http.get('http://jsonplaceholder.typicode.com/posts');
    return data;
  }
}

📦 Bonus: Customize It Further

Want to go further? Here are some ideas:

Integrate with your centralized logging service
Add request queuing or exponential backoff for specific status codes

🧘 Final Thoughts

The AdvancedAxiosService gives your NestJS applications reliable, observable, and extensible HTTP request capabilities. Whether you're calling internal APIs or external services, this service helps you build more robust apps.

Happy coding! 🚀

Enhancing NestJS Development: Improving Module Management Efficiency

amir fakoor — Wed, 15 May 2024 14:28:06 +0000

NestJS is a powerful framework for building web applications, offering a structured way to organize your code through modules. This guide will walk you through setting up your modules effectively, making your development process smoother and your codebase more manageable.

Understanding Modules in NestJS

Modules in NestJS act like containers for different parts of your application, such as user management or product listings. They help in separating concerns, making your code easier to understand and maintain.

Before: Basic Module Structure
Before adopting a structured approach, your module might look something like this:

/src
  /user
    auth.controller.ts
    user.entity.ts
    auth.service.ts
    user.module.ts

This structure mixes different types of files, making it harder to navigate and maintain as your application grows.

After: Structured Module Approach
By organizing your module with dedicated directories for each type of file, you create a clearer and more scalable structure:

/src
  /user
    /controllers
      auth.controller.ts
      profile.controller.ts
    /services
      auth.service.ts
      profile.service.ts
    /entities
      user.entity.ts
    /repositories
      user.repository.ts
    /guards
      auth.guard.ts
    user.module.ts

Organizing Your Module

To keep your module clean and easy to navigate, follow these steps:

Separate Concerns: Place each type of file (services, controllers, entities, etc.) in its own directory within the module.
Keep the Module File Simple: The user.module.ts should mainly import and configure other components, keeping the module's entry point clear and concise.

Expanding Your Module
As your application grows, you might want to add more features to your module. For example, adding a profile feature would involve:

Creating a Profile Controller: Handle requests related to user profiles.
- File path: src/user/controllers/profile.controller.ts
Adding a Profile Service: Manage the logic for fetching and updating user profiles.
- File path: src/user/services/profile.service.ts
Updating the Module: Ensure your user.module.ts imports and provides the new controller and service.

Benefits of Good Module Management

Easier Navigation: Knowing exactly where to find each part of your module speeds up development.
Better Scalability: Adding new features becomes straightforward when you have a clear structure.
Improved Collaboration: Other developers can quickly get up to speed with your project.

Final Thoughts
By organizing your NestJS modules with dedicated directories for controllers, services, entities, and other components, you create a solid foundation for your application. This approach not only makes your codebase more readable and maintainable but also prepares it for future growth and collaboration.

Unpacking the Factory Design Pattern: A Simple Guide

amir fakoor — Wed, 06 Dec 2023 00:58:43 +0000

Introduction:

Diving into the world of code can sometimes feel like you’re learning a new language. But don’t worry, let’s break down the Factory Design Pattern into everyday terms. It’s basically a super-helper, or a tool in your coding toolkit, that simplifies the way you create new chunks of code, also known as objects. It’s all about making things easier for you, keeping your code neat and making sure you can handle it no matter how big it gets.

What’s This Factory Thing Anyway?

Imagine you’re at an ice cream shop with loads of flavors. Whether you pick a cone or a cup, you can fill it with chocolate, vanilla, or strawberry without worrying about the vessel—it just works. That’s kind of what a Factory pattern does; it’s a set procedure in your code that creates different “flavors” of objects effortlessly.

Cool Reasons to Use the Factory Pattern

Think about a chef in a bustling restaurant who relies on a team following recipes to prepare dishes. The Factory Pattern in coding does something similar:

It’s your code’s recipe book: You tell it once how to make something, and it repeats the process whenever you ask.
It keeps the kitchen tidy: In your coding kitchen, you’ll have similar bits of code. The Factory Pattern helps keep them orderly.
It’s welcoming to new ideas: Adding a new type of object is easy with the Factory Pattern—you won’t need to stir up your existing code.
It’s like the head chef for making objects: You have a section in your code taking charge of how objects are put together.

Real-World Factory Example

Let’s take an online game where you can play as a knight, an archer, or a wizard. Instead of mixing complex code spells to create these characters, you use the Factory Pattern. It conjures up these characters neatly, and if you decide you want a ninja to join the fray, you can add that option quickly and painlessly.

Making It Happen with the Factory

Here’s a little TypeScript magic to show you the Factory in action:

// Define an interface that all characters must follow.
interface ICharacter {
  attack(): void;
}

// Implement the ICharacter interface with specific character classes.
class Knight implements ICharacter {
  public attack() {
    console.log("The knight swings his sword!");
  }
}

class Archer implements ICharacter {
  public attack() {
    console.log("The archer fires an arrow!");
  }
}

// Implement the ICharacter interface for newly introduced characters.
class Wizard implements ICharacter {
  public attack() {
    console.log("The wizard casts a spell!");
  }
}

// The CharacterFactory is responsible for creating instances of ICharacter.
class CharacterFactory {
  public static createCharacter(type: 'Knight' 'Archer' 'Wizard'): ICharacter {
    switch (type) {
      case 'Knight':
        return new Knight();
      case 'Archer':
        return new Archer();
      case 'Wizard':
        return new Wizard();
      default:
        throw new Error(`Character of type ${type} cannot be created.`);
    }
  }
}

// Usage of the CharacterFactory to create character instances.
const knight = CharacterFactory.createCharacter('Knight');
knight.attack();

const archer = CharacterFactory.createCharacter('Archer');
archer.attack();

const wizard = CharacterFactory.createCharacter('Wizard');
wizard.attack();

The Takeaway

The Factory Design Pattern is like a magic trick up your developer sleeve. It keeps things streamlined, flexible, and under control, especially as you’re building more complex projects. When you hear ‘Factory Pattern’, just remember the ice cream shop or the chef’s reliable recipes. It’s all about smoothing out the nitty-gritty parts of coding, so you can get back to the fun and creative side of things.

And there you have it, everything you need to know to sprinkle a bit of that Factory pattern magic into your coding projects!

Comparing GraphQL with REST API: Choosing the Right Approach for Your API

amir fakoor — Tue, 31 Oct 2023 22:34:16 +0000

Introduction:

When it comes to building APIs, developers often face the decision of choosing between GraphQL and REST API. Both approaches have their strengths and use cases, and understanding the differences can help you make an informed decision. In this article, we will compare GraphQL and REST API, providing a straightforward answer and discussing their respective use cases.

REST API: The Traditional Approach

REST (Representational State Transfer) API is an architectural style that has been widely adopted in the industry. It uses HTTP methods like GET, POST, PUT, and DELETE to interact with resources. REST APIs typically expose a fixed set of endpoints, and clients retrieve or manipulate data by making requests to these endpoints. Each request is stateless, meaning it contains all the necessary information.

Use Cases for REST API:
REST APIs are well-suited for scenarios where the data model is well-defined and the client's needs align with the server's endpoints. They are ideal for simple CRUD (Create, Read, Update, Delete) operations, where the client requires a fixed set of data. REST APIs are widely used in scenarios such as social media platforms, e-commerce websites, and content management systems.

GraphQL: The Flexible Query Language

GraphQL, on the other hand, is a query language for APIs and a runtime for executing those queries. With GraphQL, clients can request specific data by sending a query to a single endpoint. The server then responds with the requested data, typically in JSON format. GraphQL allows clients to specify exactly what data they need, reducing over-fetching or under-fetching of data.

Use Cases for GraphQL:
GraphQL shines in situations where the client's data requirements are complex or dynamic. It allows clients to retrieve multiple resources in a single request, reducing the number of round trips to the server. GraphQL is particularly useful when the client needs to aggregate data from multiple sources or when the data model is subject to change. It is commonly used in scenarios such as mobile applications, real-time data updates, and microservices architectures.

Choosing the Right Approach:

When deciding between GraphQL and REST API, it's important to consider the specific requirements of your project. If you have a well-defined data model and the client's needs align with the server's endpoints, REST API may be the simpler and more straightforward choice. REST APIs are also well-established and have extensive tooling and community support.

On the other hand, if your project involves complex or dynamic data requirements, or if you need to optimize data retrieval and reduce round trips, GraphQL can provide more flexibility and efficiency. GraphQL's ability to allow clients to request only the data they need can result in faster and more efficient API interactions.

Conclusion:

In conclusion, both GraphQL and REST API have their strengths and use cases. REST API is suitable for straightforward scenarios with fixed data requirements, while GraphQL is more flexible and efficient for complex or evolving data needs. By understanding the differences between these approaches, you can make an informed decision and choose the right approach for your API project.

GIT FLOW EASY-TO-UNDERSTAND TUTORIAL

amir fakoor — Sun, 09 Jul 2023 16:27:33 +0000

Introduction

Git Flow is a branching and release management workflow that's extremely robust. Originated by Vincent Driessen in 2010, it's a Git extension that provides high-level repository operations for managing your project's branching model.

This tutorial aims to demystify the Git Flow process, providing an anchor point for managing larger projects that require a higher degree of control over developments, releases, and hotfixes.

Setting Up Git Flow

Git Flow is an extension of Git. To use Git Flow, you need to have Git installed on your system.

For macOS users, you can install Git Flow through Homebrew using the following command: ```bash

brew install git-flow


* For Linux Debian Based users, you can install Git Flow through APT:
```bash


apt install git-flow

After Git Flow is installed, you can initialize it inside an existing Git repository by running:



git flow init

This will create the necessary branches for Git Flow and you're now ready to roll!

Git Flow Branches Explained

Here are the main types of branches you'll work with in Git Flow:

master: This contains the official history of the project. It's the credible source for the code that's gone into production.
develop: This is the development branch where all the changes destined for the next release converge.
feature: These are branches for new features. They're branched off from develop and merged back into develop.
release: This is where you prepare for a new production release. Use it to tweak new features and fix bugs.
hotfix: These are branches for quickly patching production releases. Hotfix branches are a lot like release branches and feature branches but they're based on master instead of develop.
bugfix: These are used to quickly act on bugs in the production code. They're a lot like hotfix branches but are used when the issue isn't critical and the team can afford to wait until the next release to incorporate the fix.

Git Flow Example

Let's assume that we are working on a new feature. Here's how we would use Git Flow:

Branch off from develop with a new feature branch: ```bash

git flow feature start feature_branch

2. Make your changes on your feature branch.


Once the feature is complete, merge it back to develop: 
```bash


git flow feature finish feature_branch

Conclusion

The whole essence of Git Flow is the scriptability and the fact that it provides structure to the branching and merging in your Git project. So this workflow is especially suited for continuous collaboration and iterative development in a team.

Bonus:

Check out this VS Code extension that provides a seamless integration of GitFlow directly into your editor!

Applying SOLID Principles in NestJS

amir fakoor — Mon, 03 Jul 2023 21:25:14 +0000

Introduction

In the world of software development, writing clean, maintainable, scalable code is of utmost importance. One way to achieve this is by following the SOLID principles, a set of five design principles that help developers create robust and flexible software systems.

In this article, we will explore how to apply the SOLID principles in the context of Nest, a popular framework for building scalable and modular applications with TypeScript. We will dive into each principle, providing concise code examples to illustrate their implementation in a NestJS project. the end of this guide, you will have a understanding of how to leverage these principles to write cleaner and more maintainable code in your NestJS applications. So, let's get started and level up our NestJS development with SOLID principles!

The SOLID principles we will cover in this article are:

Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

1. Single Responsibility Principle (SRP):

The Single Responsibility Principle, as the name suggests, proposes that each software module or class should have one specific role or responsibility. This principle is about cohesion in classes, and it aims to make the software design more understandable, flexible, and maintainable.

Let's consider an example in the context of a NestJS application:

// Before applying SRP
import { Injectable } from '@nestjs/common';

@Injectable()
export class UserService {
  createUser() {
    // code to create a user
  }

  deleteUser() {
    // code to delete a user
  }

  sendEmail() {
    // code to send an email
  }
}

In the above example, the UserService class is handling user management and email sending, which violates the Single Responsibility Principle.

To adhere to the SRP, we can refactor the code as follows:

// After applying SRP
import { Injectable } from '@nestjs/common';

@Injectable()
export class UserService {
  createUser() {
    // code to create a user
  }

  deleteUser() {
    // code to delete a user
  }
}

@Injectable()
export class EmailService {
  sendEmail() {
    // code to send an email
  }
}

Now, we have two separate classes, each handling a single responsibility. The UserService is responsible for user management, and the EmailService is responsible for sending emails. This makes our code more maintainable and easier to understand.

2. Open-Closed Principle (OCP):
The Open-Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. This means that a class should be easily extendable without modifying the class itself.

Let's illustrate this principle with a NestJS example:

Before applying OCP:

// greeter.service.ts
import { Injectable } from '@nestjs/common';

@Injectable()
export class GreeterService {
  greeting(type: string) {
    if (type === 'formal') {
      return 'Good day to you.';
    } else if (type === 'casual') {
      return 'Hey!';
    }
  }
}

In the above example, if we want to add a new type of greeting, we would have to modify the greeting method in the GreeterService class, which violates the Open-Closed Principle.

To adhere to the OCP, we can refactor the code as follows:

// greeting.interface.ts
export interface Greeting {
  greet(): string;
}

// formalGreeting.ts
import { Greeting } from './greeting.interface';

export class FormalGreeting implements Greeting {
  greet() {
    return 'Good day to you.';
  }
}

// casualGreeting.ts
import { Greeting } from './greeting.interface';

export class CasualGreeting implements Greeting {
  greet() {
    return 'Hey!';
  }
}

// greeter.service.ts
import { Injectable } from '@nestjs/common';
import { Greeting } from './greeting.interface';

@Injectable()
export class GreeterService {
  greeting(greeting: Greeting) {
    return greeting.greet();
  }
}

Now, each class and interface is defined in its own file, making the code more organized and easier to manage. If we want add a new type of greeting, we can simply create a implementing the Greeting interface, without modifying the existing classes. This adheres to the Open-Closed Principle.

3. Liskov Substitution Principle (LSP):
The Liskov Substitution Principle (LSP) is a concept in Object Oriented Programming that states that in a program, objects of a superclass shall be able to be replaced with objects of a subclass without affecting the correctness of the program. It is about ensuring that a subclass can stand in for its parent class without breaking the functionality of your program.

Let's illustrate this principle with a NestJS example:

class Bird {
  fly(speed: number): string {
    return `Flying at ${speed} km/h`;
  }
}

class Eagle extends Bird {
  dive(): void {
    // ...
  }

  fly(speed: number): string {
    return `Soaring through the sky at ${speed} km/h`;
  }
}

// LSP Violation:
class Penguin extends Bird {
  fly(): never {
    throw new Error("Sorry, I can't fly");
  }
}

In the above example, the Eagle class, which inherits from the Bird class, overrides the fly method with the same number of arguments, adhering to the Liskov Substitution Principle. However, the Penguin class violates the Liskov Substitution Principle because it can't fly, and thus, the fly method throws an error. This means that a Penguin object can't be substituted for a Bird object without altering the correctness of the program.

To adhere to the Liskov Substitution Principle, we need to ensure that subclasses do not alter the behavior of the parent class in such a way that could break the functionality of our program. In the case of our Bird, Eagle, and Penguin example, we could refactor the code to remove the fly method from the Bird class and instead use interfaces to define the capabilities of different types of birds.

interface FlyingBird {
  fly(speed: number): string;
}

interface NonFlyingBird {
  waddle(speed: number): string;
}

Next, we define our Eagle and Penguin classes implementing these interfaces:

class Eagle implements FlyingBird {
  fly(speed: number): string {
    return `Soaring through the sky at ${speed} km/h`;
  }
}

class Penguin implements NonFlyingBird {
  waddle(speed: number): string {
    return `Waddling at ${speed} km/h`;
  }
}

Now, we have two separate classes for Eagle and Penguin that implement different interfaces based on their abilities. This way, we are not violating the Liskov Substitution Principle because we are not pretending that a Penguin can fly. Instead, we are clearly defining what each type of bird can do and treating them differently based on their capabilities.

This approach also makes our code more flexible and easier to maintain. If we need to add a new type of bird in the future, we can simply create a new class for it and implement the appropriate interface based on its abilities.

4. Interface Segregation Principle (ISP):
The Interface Segregation Principle (ISP) states that no client should be forced to depend on methods it does not use. In other words, clients should not be forced to implement interfaces they do not use. This principle promotes the creation of fine-grained, client-specific interfaces.

The objective behind this principle is to remove unnecessary code from classes to reduce unexpected bugs when the class does not have the ability to perform an action. ISP encourages smaller, more targeted interfaces. According to this concept, multiple client-specific interfaces are preferable to a single general-purpose interface.

Let's illustrate this principle with a TypeScript example:

interface FullFeatureUser {
  viewAd(): void;
  skipAd(): void;
  startParty(): void;
}

class User {
  viewAd(): void {
    // ...
  }
}

class FreeUser extends User implements FullFeatureUser {
  skipAd(): void {
    throw new Error("Sorry, I can't skip ads");
  }

  startParty(): void {
    throw new Error("Sorry, I can't start parties");
  }
}

class PremiumUser extends User implements FullFeatureUser {
  skipAd(): void {
    // ...
  }

  startParty(): void {
    // ...
  }
}

In the above example, the FreeUser class is forced to implement the skipAd and startParty methods even though it doesn't use them. This is a violation of the Interface Segregation Principle. To adhere to the ISP, we can create more specific interfaces:

interface User {
  viewAd(): void;
}

interface PremiumFeatureUser {
  skipAd(): void;
  startParty(): void;
}

class FreeUser implements User {
  viewAd(): void {
    // ...
  }
}

class PremiumUser implements User, PremiumFeatureUser {
  viewAd(): void {
    // ...
  }

  skipAd(): void {
    // ...
  }

  startParty(): void {
    // ...
  }
}

With these changes, each class only implements the methods that it uses, adhering to the Interface Segregation Principle. This approach reduces the risk of bugs and makes our code more flexible and easier to maintain.

5. Dependency Inversion Principle (DIP):
The Dependency Inversion Principle (DIP) is the final principle in the SOLID design methodology. It states that high-level modules should not depend on low-level modules. Instead, both should depend on abstractions. Abstractions should not rely on details. Details should depend on abstractions.

The Dependency Inversion Principle is a design principle that helps to decouple software modules. This principle plays a vital role in controlling the coupling between different modules of a program.

Let's illustrate this principle with a TypeScript example:

class MySQLDatabase {
  save(data: string): void {
    // Save data to MySQL database
  }
}

class UserService {
  private database: MySQLDatabase;

  constructor(database: MySQLDatabase) {
    this.database = database;
  }

  saveUser(user: string): void {
    this.database.save(user);
  }
}

In the above example, the UserService class is tightly coupled with the MySQLDatabase class. This means that if you want to change the database system (like switching from MySQL to MongoDB), you would need to change the UserService class as well. This is a violation of the Dependency Inversion Principle.

To adhere to DIP, we can introduce an abstraction (interface) between the UserService and MySQLDatabase classes:

interface Database {
  save(data: string): void;
}

class MySQLDatabase implements Database {
  save(data: string): void {
    // Save data to MySQL database
  }
}

class UserService {
  private database: Database;

  constructor(database: Database) {
    this.database = database;
  }

  saveUser(user: string): void {
    this.database.save(user);
  }
}

Now, the UserService class depends on the Database interface, not on the concrete MySQLDatabase class. This means that you can easily switch to a different database system by creating a new class that implements the Database interface. This approach makes your code more flexible and easier to maintain.

Conclusion:

The SOLID principles are a set of design principles that help developers write clean, maintainable, and scalable code. By following these principles, you can create software systems that are easy to understand, flexible, and robust.

By understanding and applying these principles, you can your NestJS development skills and write cleaner and more maintainable code in your applications. Happy coding!

How to Upgrade NestJS 9 to 10: A Developer's Guide

amir fakoor — Sun, 25 Jun 2023 15:19:59 +0000

In this tutorial, we will walk through the process of upgrading a NestJS application from version 9 to 10. This guide is intended for developers who have an existing NestJS project and wish to update it to the latest version.

Step 1: Update the NestJS CLI
First, update the NestJS CLI to the latest version by running the following command:



npm install -g @nestjs/cli

Verify the installed version with:



nest --version

Step 2: Install npm-check-updates
To update your dependencies, install the npm-check-updates package globally:



npm i -g npm-check-updates

Step 3: Update package.json
Use ncu -u to update your package.json file with the latest dependencies:



ncu -u -f /^@nestjs/

Step 4: Verify Changes
Review the changes in your package.json file, ensuring that the NestJS dependencies are updated to the desired version (v10).

Step 5: Remove package-lock.json and node_modules
Delete the package-lock.json file and the node_modules folder with the following commands:



rm package-lock.json
rm -rf node_modules

Step 6: Install Updated Dependencies
Finally, install the updated dependencies:



npm install

Conclusion
After completing these steps, your NestJS application should be updated to version 10. Be sure to test your application thoroughly to ensure that there are no issues or breaking changes caused by the upgrade. Happy coding!

Understanding "some" and "every" Array Methods in Javascript

amir fakoor — Mon, 12 Jun 2023 19:30:15 +0000

Introduction

In this post, we'll explore two powerful array methods in Javascript: some and every. These methods are inherited from JavaScript and can be used to test elements in an array against specified conditions. We'll dive into their syntax, usage, and provide concrete examples to demonstrate their functionality.

Array.some()

The Array.some() method tests if at least one element in an array passes the provided test function. If at least one element satisfies the condition, it returns true; otherwise, it returns false.

Example

Let's say we have an array of numbers and we want to check if any of them are greater than 10.

const numbers: number[] = [1, 5, 12, 8, 3];

const hasNumberGreaterThan10 = numbers.some((num) => num > 10);
console.log(hasNumberGreaterThan10); // Output: true

In this example, the some method returns true because the number 12 is greater than 10.

Array.every()

The Array.every() method tests if all elements in an array pass the provided test function. If all elements satisfy the condition, it returns true; otherwise, it returns false.

Example

Using the same array of numbers, let's check if all of them are less than 20.

const numbers: number[] = [1, 5, 12, 8, 3];

const areAllNumbersLessThan20 = numbers.every((num) => num < 20);
console.log(areAllNumbersLessThan20); // Output: true

In this example, the every method returns true because all numbers in the array are less than 20.

Improving Code Readability with `some` and `every` Array Methods

Now, let's look at an example of how using some and every can help us write cleaner and more readable code. We will keep the previous example in the article as well.

Consider a scenario where we have an array of users, and we want to check if all users are adults and if any of them are from a specific city.

interface User {
  name: string;
  age: number;
  city: string;
}

const users: User[] = [
  { name: 'Alice', age: 25, city: 'New York' },
  { name: 'Bob', age: 30, city: 'Los Angeles' },
  { name: 'Charlie', age: 22, city: 'New York' },
];

 Without using 'some' and 'every'
function checkUsers(users: User[]): { allAdults: boolean; anyFromNewYork: boolean } {
  let allAdults = true;
  let anyFromNewYork = false;

  for (const user of users) {
    if (user.age < 18) {
      allAdults = false;
    }
    if (user.city === 'New York') {
      anyFromNewYork = true;
    }
  }

  return { allAdults, anyFromNewYork };
}

// Using 'some' and 'every'
function checkUsersWithSomeAndEvery(users: User[]): { allAdults: boolean; anyFromNewYork: boolean } {
  const allAdults = users.every((user) => user.age >= 18);
  const anyFromNewYork = users.some((user) => user.city === 'New York');

  return { allAdults, anyFromNewYork };
}

In the first checkUsers function, we use a for loop to iterate through the users array and manually update the allAdults and anyFromNewYork variables. This approach is more complex and harder to read.

In the second checkUsersWithSomeAndEvery function, we use the every and some methods to achieve the same result. This version of the function is cleaner, more readable, and easier to understand. By using these methods, we can focus on the conditions we want to check, making the code more maintainable and less error-prone.

Conclusion

The some and every array methods in TypeScript are powerful tools for testing elements in an array against specified conditions. By understanding their syntax and usage, and following best practices, you can write clean and efficient code that's easy to read and maintain.

Robust Environment Variable Validation in NestJS Applications

amir fakoor — Fri, 05 May 2023 13:21:27 +0000

Introduction:

In this article, we will explore how to validate environment variables in a NestJS application. Validating environment variables is crucial for ensuring that your application is running with the correct configuration and helps prevent runtime errors due to misconfigured or missing variables. We will use the @nestjs/config, class-transformer, and class-validator packages to achieve this.

Step 1: Install Dependencies
First, let's install the required dependencies:



npm i --save @nestjs/config class-transformer class-validator

Step 2: Create a Validation File
Create a new file named src/env.validation.ts. In this file, we will define the environment variables we want to validate, such as database configuration variables.

Here's an example of the env.validation.ts file:



import { plainToInstance } from 'class-transformer';
import { IsNumber, IsString, validateSync } from 'class-validator';

class EnvironmentVariables {
    @IsString()
    DATABASE_HOST: string;

    @IsNumber()
    DATABASE_PORT: number;

    @IsString()
    DATABASE_USERNAME: string;

    @IsString()
    DATABASE_PASSWORD: string;

    @IsString()
    DATABASE_NAME: string;
}

export function validate(config: Record<string, unknown>) {
    const validatedConfig = plainToInstance(
        EnvironmentVariables,
        config,
        { enableImplicitConversion: true },
    );
    const errors = validateSync(validatedConfig, { skipMissingProperties: false });

    if (errors.length > 0) {
        throw new Error(errors.toString());
    }
    return validatedConfig;
}

In this file, we define a class EnvironmentVariables with the required properties and their validation decorators. The validate function takes a configuration object, converts it to an instance of EnvironmentVariables, and validates it using validateSync. If there are any validation errors, an exception is thrown.

Step 3: Load ConfigModule in AppModule
Next, we need to load the ConfigModule in our app.module.ts file and provide the validate function we created earlier:



import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { validate } from './env.validation';

@Module({
  imports: [
    ConfigModule.forRoot({
      validate,
      isGlobal: true
    }),
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule { }

Step 4: Create a .env File
Create a .env file in the root of your project with the required environment variables. For example:



DATABASE_HOST=postgres
DATABASE_PORT=5432
DATABASE_USERNAME=postgres
DATABASE_PASSWORD=dev-secret
DATABASE_NAME=postgres

Now, when you run your NestJS application, it should start successfully if all environment variables are correctly configured.

However, if any environment variable is missing or has an incorrect value, an exception will be thrown, and the application will not start.

For example, if we comment out the DATABASE_NAME variable in the .env file and restart the application:

Conclusion:

Validating environment variables in your NestJS application is an effective way to ensure that your application is running with the correct configuration and to catch errors early in the development process. By using the @nestjs/config, class-transformer, and class-validator packages, you can easily implement robust validation for your environment variables.

Tips to Use Constants File in TypeScript

amir fakoor — Thu, 04 May 2023 11:43:40 +0000

Introduction

In TypeScript, a constants file is a useful way to store and manage constant values that are used throughout your application. By centralizing these values in a single location, you can easily maintain and update them, leading to cleaner and more maintainable code. In this article, we will discuss some tips on how to effectively use a constants file in your TypeScript projects.

Tip 1: Create a dedicated constants file

Start by creating a dedicated file for your constants, typically named constants.ts. This file should be placed in a logical location within your project structure, such as in a src or utils folder. By keeping all your constants in one place, you can easily locate and update them as needed.

// src/constants.ts

export const API_URL = 'https://api.example.com';
export const MAX_RETRIES = 3;
export const TIMEOUT = 5000;

Tip 2: Use the const keyword and meaningful names

When defining constants, use the const keyword to ensure their values cannot be changed. Additionally, give your constants meaningful and descriptive names, using uppercase letters and underscores to separate words. This naming convention makes it clear that the variable is a constant and improves code readability.

// src/constants.ts

export const MAXIMUM_CONNECTIONS = 10;
export const DEFAULT_LANGUAGE = 'en';

Tip 3: Organize constants by category

If your project has a large number of constants, it can be helpful to organize them by category. You can use namespaces or separate files for each category, depending on your preference. This organization makes it easier to locate and manage constants related to specific features or modules.

// src/constants/api.ts

export const API_URL = 'https://api.example.com';
export const MAX_RETRIES = 3;
export const TIMEOUT = 5000;

// src/constants/ui.ts

export const DEFAULT_LANGUAGE = 'en';
export const THEME_COLOR = '#007bff';

Tip 4: Use constants for reusable values

Constants are particularly useful for values that are reused throughout your application. By using constants, you can avoid hardcoding these values in multiple places, making your code more maintainable and less prone to errors.

// src/utils/request.ts

import { API_URL, MAX_RETRIES, TIMEOUT } from '../constants/api';

export async function fetchData(endpoint: string) {
  const url = `${API_URL}/${endpoint}`;
  // Use MAX_RETRIES and TIMEOUT constants in your request logic
}

Tip 5: Document your constants

To ensure that your constants are easily understood by other developers, provide clear and concise documentation. This can be done using comments or, for more complex constants, using JSDoc annotations.

// src/constants.ts

/**
 * The base URL for the API.
 * @constant
 */
export const API_URL = 'https://api.example.com';

/**
 * The maximum number of retries for API requests.
 * @constant
 */
export const MAX_RETRIES = 3;

/**
 * The timeout duration for API requests, in milliseconds.
 * @constant
 */
export const TIMEOUT = 5000;

Conclusion

Using a constants file in your TypeScript projects can greatly improve code maintainability and readability. By following these tips, you can effectively manage your constants and ensure that your application remains easy to update and modify as it grows.

Using TypeORM Migration in NestJS with Postgres Database

amir fakoor — Wed, 03 May 2023 16:45:42 +0000

If you are building a NestJS application and want to use a PostgreSQL database with TypeORM migration, then this article will guide you on creating and running migrations efficiently.

First, create a NestJS application with Nest CLI:

nest new my-app

Next, install the required packages for TypeORM, Postgres, and Configuration:

npm install --save @nestjs/typeorm typeorm pg @nestjs/config

Create a file to store the TypeORM configuration in the src/config/typeorm.ts directory. This file should export a TypeORM configuration object and a connection source object.

import { registerAs } from "@nestjs/config";
import { config as dotenvConfig } from 'dotenv';
import { DataSource, DataSourceOptions } from "typeorm";

dotenvConfig({ path: '.env' });

const config = {
    type: 'postgres',
    host: `${process.env.DATABASE_HOST}`,
    port: `${process.env.DATABASE_PORT}`,
    username: `${process.env.DATABASE_USERNAME}`,
    password: `${process.env.DATABASE_PASSWORD}`,
    database: `${process.env.DATABASE_NAME}`,
    entities: ["dist/**/*.entity{.ts,.js}"],
    migrations: ["dist/migrations/*{.ts,.js}"],
    autoLoadEntities: true,
    synchronize: false,
}

export default registerAs('typeorm', () => config)
export const connectionSource = new DataSource(config as DataSourceOptions);

Load TypeORM into app.module.ts to use it in your NestJS application:

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { TypeOrmModule } from '@nestjs/typeorm';
import typeorm from './config/typeorm';

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      load: [typeorm]
    }),
    TypeOrmModule.forRootAsync({
      inject: [ConfigService],
      useFactory: async (configService: ConfigService) => (configService.get('typeorm'))
    }),
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule { }

Create a .env file in the src/ directory to define the variables in your typeorm.ts file:

DATABASE_HOST=postgres
DATABASE_PORT=5432
DATABASE_USERNAME=postgres
DATABASE_PASSWORD=dev-secret
DATABASE_NAME=postgres

Add the TypeORM migration commands into your package.json file:

"scripts": {
    // ...
    "typeorm": "ts-node ./node_modules/typeorm/cli",
    "migration:run": "npm run typeorm migration:run -- -d ./src/config/typeorm.ts",
    "migration:generate": "npm run typeorm -- -d ./src/config/typeorm.ts migration:generate ./src/migrations/$npm_config_name",
    "migration:create": "npm run typeorm -- migration:create ./src/migrations/$npm_config_name",
    "migration:revert": "npm run typeorm -- -d ./src/config/typeorm.ts migration:revert"
  },

To execute migration, use the following command:

npm run migration:run

To create a new migration, use the following command:

npm run migration:create --name=your_migration_name

That's it! With this guide, you should now be able to use TypeORM migration with Postgres in your NestJS application efficiently.

How to DRY Up Your NestJS DTOs

amir fakoor — Tue, 25 Apr 2023 18:56:00 +0000

Introduction:

In NestJS, Data Transfer Objects (DTOs) are used to define the shape of data for various operations, such as creating or updating entities. However, it's common to have similar properties between DTOs for creating and updating entities, which can lead to redundancy in your code. In this post, we'll explore a smart way to reduce redundancy in NestJS DTOs using class inheritance and the PartialType utility provided by the @nestjs/mapped-types package.

Step 1: Install the @nestjs/mapped-types package

First, you'll need to install the @nestjs/mapped-types package, which provides the PartialType utility:

npm install @nestjs/mapped-types

Step 2: Create a base DTO for creating a new entity

Let's create a base DTO for creating a new user. This will be our CreateUserDto:

// create-user.dto.ts
export class CreateUserDto {
  firstName: string;
  lastName: string;
  email: string;
  password: string;
}

Step 3: Create an update DTO for updating an entity using class inheritance and PartialType

Now, we'll create an UpdateUserDto by extending the CreateUserDto and using the PartialType utility. This will make all properties from CreateUserDto optional in UpdateUserDto:

// update-user.dto.ts
import { PartialType } from '@nestjs/mapped-types';
import { CreateUserDto } from './create-user.dto';

export class UpdateUserDto extends PartialType(CreateUserDto) {}

Conclusion:

By using class inheritance and the PartialType utility, we've successfully reduced redundancy in our NestJS DTOs. The UpdateUserDto inherits all properties from CreateUserDto, but they are optional due to the PartialType utility. This keeps your code DRY (Don't Repeat Yourself) and makes it easier to maintain.

When you need to update your DTOs, you only need to modify the base DTO (CreateUserDto), and the changes will automatically be reflected in the UpdateUserDto. This approach helps you write cleaner and more maintainable code in your NestJS applications.

DEV Community: amir fakoor

✨ Build a Better Axios Client in NestJS

🎯 Why Use a Custom Axios Service?

📦 Install Dependencies

🛠️ The Service Implementation

🧪 How to Use It

📦 Bonus: Customize It Further

🧘 Final Thoughts

Enhancing NestJS Development: Improving Module Management Efficiency

Understanding Modules in NestJS

Organizing Your Module

Unpacking the Factory Design Pattern: A Simple Guide

Introduction:

What’s This Factory Thing Anyway?

Cool Reasons to Use the Factory Pattern

Real-World Factory Example

Making It Happen with the Factory

The Takeaway

Comparing GraphQL with REST API: Choosing the Right Approach for Your API

Introduction:

REST API: The Traditional Approach

GraphQL: The Flexible Query Language

Choosing the Right Approach:

Conclusion:

GIT FLOW EASY-TO-UNDERSTAND TUTORIAL

Introduction

Setting Up Git Flow

Git Flow Branches Explained

Git Flow Example

Conclusion

Bonus:

Applying SOLID Principles in NestJS

Introduction

Conclusion:

How to Upgrade NestJS 9 to 10: A Developer's Guide

Understanding "some" and "every" Array Methods in Javascript

Introduction

Array.some()

Example

Array.every()

Example

Improving Code Readability with some and every Array Methods

Conclusion

Robust Environment Variable Validation in NestJS Applications

Introduction:

Conclusion:

Tips to Use Constants File in TypeScript

Introduction

Conclusion

Using TypeORM Migration in NestJS with Postgres Database

How to DRY Up Your NestJS DTOs

Introduction:

Conclusion:

Improving Code Readability with `some` and `every` Array Methods