DEV Community: Amir Ehsan Ahmadzadeh

NestJS Fundamentals Part 1: Modularity in NestJS

Amir Ehsan Ahmadzadeh — Tue, 21 Jan 2025 13:55:53 +0000

When building scalable applications with NestJS, understanding its modular architecture is the first and most critical step. Modules are at the heart of every NestJS application, organizing your code into manageable, reusable, and maintainable components.

NestJS’s modular architecture works closely with its Dependency Injection (DI) system, which enables the decoupling of application logic and improves testability and maintainability. If you’re unfamiliar with concepts like DI, IoC (Inversion of Control), or the Dependency Inversion principle, I’ve created a blog post to help you understand these foundational ideas. You can check it out here.

This guide is Part 1 of the NestJS Fundamentals series, where we’ll explore how to leverage the @Module decorator to design modular applications. Future parts of this series will cover controllers, dependency injection in practice, middleware, testing, and more. By the end of this series, you’ll have a deep understanding of NestJS and how to use it effectively.

Let’s dive into modularity in NestJS and master the inputs of the @Module decorator.

What is the Module Decorator?
Inputs of the Module Decorator
- Providers
- Controllers
- Imports
- Exports
- Global
- Scope
Practical Example: A Modular NestJS Application
FAQs About NestJS Modules

What is the Module Decorator?

The @Module decorator in NestJS is used to define the metadata of a module. A module organizes your application into smaller, reusable building blocks, each responsible for a specific piece of functionality. This modular approach enhances scalability and maintainability in applications.

For more details, visit the official NestJS documentation on modules.

Inputs of the Module Decorator

The @Module decorator accepts several inputs that define the structure and behavior of a module. These inputs include:

Providers

Providers are the backbone of NestJS’s dependency injection system. They encapsulate reusable business logic, services, or utilities that can be injected into other parts of your application.

Default Scope: Providers are module-scoped by default, meaning they are available only within the module they are defined in.

Example:

// src/services/my.service.ts
import { Injectable } from '@nestjs/common';

@Injectable()
export class MyService {
  private data = 'Hello, NestJS!';

  getData(): string {
    return this.data;
  }
}

Controllers

Controllers define routes and handle incoming HTTP requests. They are specified in the controllers array within a module.

Example:

// src/controllers/user.controller.ts
import { Controller, Get } from '@nestjs/common';

@Controller('users')
export class UserController {
  @Get()
  getAllUsers() {
    return 'List of users';
  }
}

// src/modules/user.module.ts
import { Module } from '@nestjs/common';
import { UserController } from '../controllers/user.controller';

@Module({
  controllers: [UserController],
})
export class UserModule {}

Imports

The imports array allows a module to include and use other modules. By importing a module, you gain access to its exported providers.

Example:

// src/modules/app.module.ts
import { Module } from '@nestjs/common';
import { UserModule } from './user.module';

@Module({
  imports: [UserModule], // Importing UserModule
})
export class AppModule {}

Exports

The exports array specifies which providers from the current module are available for use in other modules. Without exporting, providers remain private to the module.

Example:

// src/modules/user.module.ts
import { Module } from '@nestjs/common';
import { MyService } from '../services/my.service';

@Module({
  providers: [MyService],
  exports: [MyService], // Making MyService accessible to other modules
})
export class UserModule {}

Global

The global property makes a module automatically available across the application without needing to explicitly import it in other modules.

Example:

// src/modules/global.module.ts
import { Module } from '@nestjs/common';
import { MyService } from '../services/my.service';

@Module({
  providers: [MyService],
  exports: [MyService],
  global: true, // Marks the module as globally available
})
export class GlobalModule {}

Scope

The scope property allows you to customize the lifecycle of a provider. The available scopes are:

Singleton (default): A single instance is shared across the application.
Request: A new instance is created for each HTTP request.
Transient: A new instance is created each time it is injected.

Example:

// src/services/request-scoped.service.ts
import { Injectable, Scope } from '@nestjs/common';

@Injectable({ scope: Scope.REQUEST })
export class RequestScopedService {}

Practical Example: A Modular NestJS Application

Here’s a real-world scenario demonstrating how the module decorator inputs work together:

Step 1: Define a Shared Provider

// src/services/shared.service.ts
import { Injectable } from '@nestjs/common';

@Injectable()
export class SharedService {
  private message = 'Shared Message';

  getMessage() {
    return this.message;
  }

  setMessage(newMessage: string) {
    this.message = newMessage;
  }
}

Step 2: Create and Export a Module

// src/modules/shared.module.ts
import { Module } from '@nestjs/common';
import { SharedService } from '../services/shared.service';

@Module({
  providers: [SharedService],
  exports: [SharedService], // Export SharedService to make it accessible
})
export class SharedModule {}

Step 3: Import the Module and Use the Provider

// src/modules/app.module.ts
import { Module } from '@nestjs/common';
import { SharedModule } from './shared.module';
import { AppController } from '../controllers/app.controller';

@Module({
  imports: [SharedModule], // Importing SharedModule
  controllers: [AppController],
})
export class AppModule {}

// src/controllers/app.controller.ts
import { Controller, Get } from '@nestjs/common';
import { SharedService } from '../services/shared.service';

@Controller()
export class AppController {
  constructor(private readonly sharedService: SharedService) {}

  @Get()
  getSharedData() {
    return this.sharedService.getMessage();
  }
}

Here’s the improved FAQs About NestJS Modules section with better, practical, and engaging questions that address common challenges and curiosities about modularity in NestJS:

FAQs About NestJS Modules

1. What is the purpose of modularity in NestJS?

Modularity allows you to divide your application into feature-specific units called modules. This:

Promotes code reusability.
Enhances maintainability by isolating features.
Simplifies scaling by making it easier to manage and extend modules.

2. How do I decide what should go into a module?

Each module should encapsulate a specific feature or closely related functionalities. Examples:

UserModule for user management (authentication, profiles).
ProductModule for product operations.
SharedModule for utilities like logging or configuration.

3. What’s the difference between `providers`, `exports`, and `imports`?

Providers: Internal services or logic available within the module.
Exports: Providers made available to other modules that import the module.
Imports: A way for a module to access the exports of another module.

Example:

@Module({
  providers: [FeatureService],
  exports: [FeatureService], // Makes FeatureService reusable
})
export class FeatureModule {}

@Module({
  imports: [FeatureModule], // Accessing exports of FeatureModule
})
export class AppModule {}

4. When should I use `global: true` for a module?

Use global: true when you need application-wide accessibility for a module (e.g., ConfigModule, LoggerModule). Avoid overuse to prevent unintended dependencies.

5. How does the `scope` of providers affect their lifecycle?

Singleton (default): One shared instance across the app.
Request: A new instance for each HTTP request.
Transient: A new instance every time it’s injected.

Example:

@Injectable({ scope: Scope.REQUEST })
export class RequestScopedService {}

6. Can I import the same module into multiple other modules?

Yes! NestJS ensures that exported providers remain singletons unless explicitly scoped otherwise.

7. How do I handle circular dependencies between modules?

Use forwardRef() to resolve circular dependencies:

@Injectable()
export class AService {
  constructor(@Inject(forwardRef(() => BService)) private bService: BService) {}
}

8. How do I test a module in isolation?

Use Test.createTestingModule() to create an isolated testing environment. Override providers to use mock implementations.

Example:

const module = await Test.createTestingModule({
  imports: [UserModule],
})
  .overrideProvider(UserService)
  .useValue(mockUserService)
  .compile();

9. How do shared modules work in NestJS?

A shared module exports providers to be reused across multiple modules. Exported providers remain singletons.

Example:

@Module({
  providers: [LoggingService],
  exports: [LoggingService],
})
export class SharedModule {}

10. How should I organize modules in a large NestJS application?

Structure modules by feature or domain for scalability:

src/
├── app.module.ts
├── modules/
│   ├── auth/
│   │   ├── auth.module.ts
│   │   ├── auth.service.ts
│   │   ├── auth.controller.ts
│   ├── users/
│   │   ├── users.module.ts
│   │   ├── users.service.ts
│   │   ├── users.controller.ts
│   ├── shared/
│       ├── shared.module.ts
│       ├── logging.service.ts

The @Module decorator is the foundation of NestJS’s modular architecture. By understanding and leveraging its inputs—providers, controllers, imports, exports, global, and scope—you can create scalable, maintainable, and reusable application structures.

If this guide helped you, don’t forget to share it or leave a comment. Let’s discuss your experience with NestJS modules below!

Breaking Down Dependency Inversion, IoC, and DI

Amir Ehsan Ahmadzadeh — Sun, 19 Jan 2025 15:18:59 +0000

I was, knee-deep in the dependency injection system of NestJS, trying to figure out how it all worked. You know that feeling when you’re exploring something and suddenly realize there are concepts you kind of know, but not really? That’s where I was with Dependency Inversion, Inversion of Control, and Dependency Injection.

These three ideas seem so similar at first. But the deeper I dug, the more it became clear: they’re connected, but they solve different problems. I figured I’d write this as a refresher for myself—and for anyone else who’s been staring at these terms and wondering how they all fit together.

1. Dependency Inversion Principle (DIP)

Definition:

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

What Does This Mean?

In software, a high-level module contains core business logic, while low-level modules handle specific implementation details (e.g., file systems, databases, or APIs). Without DIP, high-level modules directly depend on low-level modules, creating tight coupling that:

Reduces flexibility.
Complicates testing and maintenance.
Increases effort to replace or extend low-level details.

DIP flips this relationship. Instead of the high-level module controlling low-level implementation, both depend on a shared abstraction (like an interface or abstract class).

Without DIP

Python Example

class EmailService:
    def send_email(self, message):
        print(f"Sending email: {message}")

class Notification:
    def __init__(self):
        self.email_service = EmailService()

    def notify(self, message):
        self.email_service.send_email(message)

TypeScript Example

class EmailService {
    sendEmail(message: string): void {
        console.log(`Sending email: ${message}`);
    }
}

class Notification {
    private emailService: EmailService;

    constructor() {
        this.emailService = new EmailService();
    }

    notify(message: string): void {
        this.emailService.sendEmail(message);
    }
}

Problems:

Tight coupling: Notification depends on EmailService.
Hard to extend: Switching to an SMSService or a PushNotificationService requires modifying Notification.

With DIP

Python Example

from abc import ABC, abstractmethod

class MessageService(ABC):
    @abstractmethod
    def send_message(self, message):
        pass

class EmailService(MessageService):
    def send_message(self, message):
        print(f"Sending email: {message}")

class Notification:
    def __init__(self, message_service: MessageService):
        self.message_service = message_service

    def notify(self, message):
        self.message_service.send_message(message)

# Usage
email_service = EmailService()
notification = Notification(email_service)
notification.notify("Hello, Dependency Inversion!")

TypeScript Example

interface MessageService {
    sendMessage(message: string): void;
}

class EmailService implements MessageService {
    sendMessage(message: string): void {
        console.log(`Sending email: ${message}`);
    }
}

class Notification {
    private messageService: MessageService;

    constructor(messageService: MessageService) {
        this.messageService = messageService;
    }

    notify(message: string): void {
        this.messageService.sendMessage(message);
    }
}

// Usage
const emailService = new EmailService();
const notification = new Notification(emailService);
notification.notify("Hello, Dependency Inversion!");

Benefits of DIP

Flexibility: Swap implementations without modifying high-level modules.
Testability: Replace real dependencies with mock versions for testing.
Maintainability: Changes in low-level modules don’t affect high-level modules.

2. Inversion of Control (IoC)

IoC is a design principle where the control of dependencies is transferred to an external system or framework, rather than managed within the class itself.

In traditional programming, a class creates and manages its dependencies. IoC flips this control—an external entity (e.g., a framework or container) manages dependencies and injects them where needed.

Without IoC

In a setup without IoC, the class itself is responsible for creating and managing its dependencies, leading to tight coupling. Let’s see examples in Python and TypeScript:

Python Example: Without IoC

class SMSService:
    def send_message(self, message):
        print(f"Sending SMS: {message}")

class Notification:
    def __init__(self):
        # Dependency is created inside the class
        self.sms_service = SMSService()

    def notify(self, message):
        self.sms_service.send_message(message)

# Usage
notification = Notification()
notification.notify("Hello, tightly coupled dependencies!")

TypeScript Example: Without IoC

class SMSService {
    sendMessage(message: string): void {
        console.log(`Sending SMS: ${message}`);
    }
}

class Notification {
    private smsService: SMSService;

    constructor() {
        // Dependency is created inside the class
        this.smsService = new SMSService();
    }

    notify(message: string): void {
        this.smsService.sendMessage(message);
    }
}

// Usage
const notification = new Notification();
notification.notify("Hello, tightly coupled dependencies!");

Problems Without IoC:

Tight coupling: The Notification class directly creates and depends on the SMSService class.
Low flexibility: Switching to a different implementation (e.g., EmailService) requires modifying the Notification class.
Difficult testing: Mocking dependencies for unit tests is challenging because the dependencies are hardcoded.

With IoC

In the With IoC examples, we shift the responsibility of managing dependencies to an external system or a framework, achieving loose coupling and enhancing testability.

Python Example: With IoC

class SMSService:
    def send_message(self, message):
        print(f"Sending SMS: {message}")

class Notification:
    def __init__(self, message_service):
        # Dependency is injected externally
        self.message_service = message_service

    def notify(self, message):
        self.message_service.send_message(message)

# IoC: Dependency is controlled externally
sms_service = SMSService()
notification = Notification(sms_service)
notification.notify("Hello, Inversion of Control!")

TypeScript Example: With IoC

class SMSService {
    sendMessage(message: string): void {
        console.log(`Sending SMS: ${message}`);
    }
}

class Notification {
    private messageService: SMSService;

    constructor(messageService: SMSService) {
        // Dependency is injected externally
        this.messageService = messageService;
    }

    notify(message: string): void {
        this.messageService.sendMessage(message);
    }
}

// IoC: Dependency is controlled externally
const smsService = new SMSService();
const notification = new Notification(smsService);
notification.notify("Hello, Inversion of Control!");

Benefits of IoC

Loose coupling: Classes don’t create their dependencies, making them less dependent on specific implementations.
Easy to switch implementations: Replace a SMSService with an EmailService without modifying the core class.
Improved testability: Inject mock or fake dependencies during testing.

3. Dependency Injection (DI)

DI is a technique where an object receives its dependencies from an external source rather than creating them itself.

DI is a practical implementation of IoC. It allows developers to "inject" dependencies into classes in various ways:

Constructor Injection: Dependencies are passed via the constructor.
Setter Injection: Dependencies are set via public methods.
Interface Injection: Dependencies are provided through an interface.

Python Example: DI Framework

Using the injector library:

from injector import Injector, inject

class EmailService:
    def send_message(self, message):
        print(f"Email sent: {message}")

class Notification:
    @inject
    def __init__(self, email_service: EmailService):
        self.email_service = email_service

    def notify(self, message):
        self.email_service.send_message(message)

# DI Container
injector = Injector()
notification = injector.get(Notification)
notification.notify("This is Dependency Injection in Python!")

Note: Be aware that the injector relies on Python type annotations; So it will distinguish dependencies based on type hints.

TypeScript Example: DI Framework

Using tsyringe:

import "reflect-metadata";
import { injectable, inject, container } from "tsyringe";

@injectable()
class EmailService {
    sendMessage(message: string): void {
        console.log(`Email sent: ${message}`);
    }
}

@injectable()
class Notification {
    constructor(@inject(EmailService) private emailService: EmailService) {}

    notify(message: string): void {
        this.emailService.sendMessage(message);
    }
}

// DI Container
const notification = container.resolve(Notification);
notification.notify("This is Dependency Injection in TypeScript!");

Benefits of DI

Simplifies Testing: Easily replace dependencies with mock objects.
Improves Scalability: Add new implementations without modifying existing code.
Enhances Maintainability: Reduces the impact of changes in one part of the system.

Why 'this' in JavaScript Differs from Other OOP Languages

Amir Ehsan Ahmadzadeh — Fri, 17 Jan 2025 06:17:12 +0000

One of the most confusing aspects of JavaScript for me was understanding how the this keyword works.

The this keyword in JavaScript behaves differently from OOP languages like C#, Java, or Python (where the equivalent is self) because of how this is determined. In those languages, this consistently refers to the current instance of the class or object. In JavaScript, however, this is more dynamic and its value depends on how and where a function is invoked.

With that in mind, I decided to create a summary of the different scenarios where the behavior of this can vary. Here's the breakdown:

1. Global Context

Non-Strict Mode:

this refers to the global object (window in browsers, global in Node.js).

console.log(this); // `window` or `global`

Strict Mode:

this is undefined.

"use strict";
console.log(this); // undefined

2. Inside a Function

Regular Function:

In non-strict mode, this refers to the global object.
In strict mode, this is undefined.

function myFunction() {
    console.log(this);
}
myFunction(); // `window` (non-strict), undefined (strict)

3. As a Method of an Object

When a function is called as a method of an object, this refers to the object that owns the method.

const obj = {
    name: "JavaScript",
    greet() {
        console.log(this.name); // `this` refers to `obj`
    }
};
obj.greet(); // Output: "JavaScript"

4. Arrow Functions

Arrow functions do not have their own this. Instead, they inherit this from their lexical scope (the surrounding context).

const obj = {
    name: "JavaScript",
    arrowFunc: () => {
        console.log(this.name); // `this` is inherited from the global scope
    }
};
obj.arrowFunc(); // undefined (in browsers, `this` is `window`)

function outer() {
    const arrow = () => console.log(this);
    arrow(); // Inherits `this` from `outer`'s context
}
outer();

5. In a Constructor

In a constructor function or class, this refers to the instance being created.

class Person {
    constructor(name) {
        this.name = name;
    }
    greet() {
        console.log(`Hello, ${this.name}`);
    }
}

const person = new Person("Alice");
person.greet(); // Output: Hello, Alice

6. Explicit Binding (`call`, `apply`, `bind`)

In JavaScript, functions are objects and have methods like call, apply, and bind, which let you explicitly set the value of this.

`call` and `apply`:

Invoke the function with a specified this value.
Difference: call accepts arguments as a comma-separated list; apply takes an array.

function greet(greeting) {
    console.log(`${greeting}, ${this.name}`);
}

const user = { name: "Alice" };
greet.call(user, "Hello"); // Output: Hello, Alice
greet.apply(user, ["Hi"]); // Output: Hi, Alice

`bind`:

Returns a new function with this permanently bound to the specified value.

const boundGreet = greet.bind(user);
boundGreet("Hello"); // Output: Hello, Alice

7. In an Event Listener

Regular Function:

this refers to the element that triggered the event.

const button = document.querySelector("button");
button.addEventListener("click", function () {
    console.log(this); // The button element
});

Arrow Function:

this inherits from the surrounding scope, not the element.

button.addEventListener("click", () => {
    console.log(this); // `this` depends on where the arrow function is defined
});

8. Inside `setTimeout` or `setInterval`

Regular Function:

this defaults to the global object (window).

setTimeout(function () {
    console.log(this); // `window` in browsers
}, 1000);

Arrow Function:

Inherits this from its lexical scope.

setTimeout(() => {
    console.log(this); // Inherits `this` from the surrounding context
}, 1000);

9. In Classes

Inside a class method, this refers to the class instance.

class MyClass {
    constructor(name) {
        this.name = name;
    }

    sayName() {
        console.log(this.name);
    }
}

const obj = new MyClass("JavaScript");
obj.sayName(); // Output: JavaScript

10. Losing Context (Method Extraction)

When a method is assigned to a variable or passed as a callback, this can lose its binding.

const obj = {
    name: "JavaScript",
    greet() {
        console.log(this.name);
    }
};

const greet = obj.greet;
greet(); // undefined (`this` is no longer bound to `obj`)

Solutions:

Use bind:

   const boundGreet = obj.greet.bind(obj);
   boundGreet(); // Output: JavaScript

Use an Arrow Function:

   const obj = {
       name: "JavaScript",
       greet: () => console.log(this.name) // `this` is inherited lexically
   };
   obj.greet(); // Output depends on outer scope

11. In `new` Keyword Usage

When you use new with a function or class, this refers to the newly created object.

function MyConstructor() {
    this.name = "New Object";
}
const instance = new MyConstructor();
console.log(instance.name); // Output: New Object

Summary

Context	`this` Refers To
Global (non-strict)	Global object (`window`/`global`).
Global (strict)	`undefined`.
Object Method	The object that owns the method.
Arrow Function	Inherits `this` from the enclosing context.
Constructor/Class	The instance being created.
`call`, `apply`, `bind`	Explicitly defined value.
Event Listener	The element that triggered the event.
`setTimeout/Interval`	Global object or inherited context (arrow).
`new` Keyword	The newly created object.

Why Use Getters and Setters?!

Amir Ehsan Ahmadzadeh — Wed, 18 Dec 2024 22:39:21 +0000

If you’ve worked with Python or JavaScript or any other language that supports OOP, you’ve likely come across getters and setters—special methods used to access or modify an object’s attributes. But if we can directly change attributes like this:

class Person:
    def __init__(self, name):
        self.name = name  # Directly accessible attribute

# Usage
p = Person("Alice")
print(p.name)  # Access directly
p.name = "Bob"  # Modify directly
print(p.name)

Why would we ever need getters and setters? Isn’t this redundant?

It’s a valid question. In this article, we’ll break down why getters and setters are useful, when you should use them, and when you can skip them.

What Are Getters and Setters?

In object-oriented programming, getters and setters are methods used to access and modify an object's attributes. Here's a simple example in Python:

class Person:
    def __init__(self, name):
        self._name = name  # Protected attribute

    @property
    def name(self):
        return self._name  # Getter

    @name.setter
    def name(self, value):
        if not value:
            raise ValueError("Name cannot be empty")  # Validation
        self._name = value  # Setter

In JavaScript, it looks like this:

class Person {
    constructor(name) {
        this._name = name; // Protected attribute
    }

    get name() {
        return this._name; // Getter
    }

    set name(value) {
        if (!value) {
            throw new Error("Name cannot be empty"); // Validation
        }
        this._name = value; // Setter
    }
}

By wrapping attributes in methods, you gain control over how they’re accessed or modified.

Why Not Access Attributes Directly?

The argument for direct access is simplicity. Why add extra layers when you can just do this?

class Person:
    def __init__(self, name):
        self.name = name  # Use a regular attribute


# Try to changing it directly
p = Person("Alice")
print(p.name)
p.name = "Bob"
print(p.name)

# Output: 
# Alice
# Bob

This works, but it leaves your attributes vulnerable to unintended or invalid changes. Let’s explore why getters and setters matter:

Validation and Control

Direct access gives you no way to enforce rules for the attribute’s value. For instance, consider a Person class where the name attribute must never be empty. With a setter, you can validate the value:
Python:

@name.setter
def name(self, value):
    if not value:
        raise ValueError("Name cannot be empty")

JavaScript:

set name(value) {
    if (!value) {
        throw new Error("Name cannot be empty");
    }
    this._name = value;
}

Without this, invalid values can sneak in:

p.name = ""  # No error without a setter!

Read-Only Properties

Some attributes should only be readable, not writable. Getters allow you to expose data without allowing modifications.

Example: Calculating age from birth_year:
Python:

from datetime import date

class Person:
    def __init__(self, name, birth_year):
        self.name = name
        self.birth_year = birth_year

    @property
    def age(self):
        return date.today().year - self.birth_year  # Read-only attribute

JavaScript:

class Person {
    constructor(name, birthYear) {
        this.name = name;
        this.birthYear = birthYear;
    }

    get age() {
        return new Date().getFullYear() - this.birthYear; // Read-only attribute
    }
}

Users can read age but not modify it directly:

p.age = 30  # Throws an error

Future-Proofing

Exposing an attribute directly ties your internal implementation to your class's public interface. If you later decide to add logic (e.g., validating or formatting values), you’ll need to refactor all code that directly accesses the attribute.

Using getters and setters from the start makes future changes seamless.

Example: Changing how name is stored:

Python:

@name.setter
def name(self, value):
    self._name = value.capitalize()  # Always capitalize names

JavaScript:

set name(value) {
    this._name = value.toUpperCase(); // Always store in uppercase
}

With direct access, these changes would break existing code.

Lazy Computation

Python:

class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height
        self._area = None

    @property
    def area(self):
        if self._area is None:
            self._area = self.width * self.height
        return self._area

JavaScript:

get area() {
    if (!this._area) {
        this._area = this.width * this.height;
    }
    return this._area;
}

Benefits of Using Getters and Setters

1. Better Control
Getters and setters give you fine-grained control over how attributes are accessed and modified. They allow you to enforce rules, validate input, or transform data as needed, ensuring consistency and reliability.

2. Encapsulation
They support encapsulation by hiding the internal implementation of attributes and exposing only what is necessary. This helps maintain a clean, modular, and maintainable class design.

3. Reusability
By implementing logic directly within setters, you eliminate the need for external validation or transformation code. This centralization ensures that users of the class don’t need to write additional code to handle common operations, such as validation or formatting. As a result, your class becomes easier to use and more consistent across different parts of your project.

4. Security
Restricting direct access to attributes provides an added layer of security. Sensitive or critical data is protected from accidental or unauthorized modifications, enhancing the robustness of your code.

5. Future-Proofing
Getters and setters decouple the attribute’s external access from its internal implementation. This makes it easier to adapt to future changes, such as adding new features, validations, or logic, without breaking existing code.

What Do You Think?

Have you used getters and setters in your projects? Are they overkill, or do they help you write better code? Share your thoughts in the comments!

RAG Explained: Tackling the Big Problems in AI

Amir Ehsan Ahmadzadeh — Sat, 14 Dec 2024 18:22:02 +0000

This is the post about understanding concept of RAG, but before diving into the core concept of Retrieval-Augmented Generation (RAG), I want to share a little bit about myself and the approach I take when learning something new. I’m new here and excited to be part of this community, so here’s a quick intro to my learning philosophy.

My Learning Philosophy

When it comes to exploring new technologies or concepts, I try to ensure they are worth my time by focusing on approaches or tools that are widely recognized as good practices. Time is valuable, so learning something impactful is always the goal.

I like to begin with a top-down approach by asking myself two key questions:

What problem does this aim to solve?
How were these problems addressed before this tool/technology existed?

These questions help me understand not just the “what” but also the “why” of a technology. With that in mind, let’s explore RAG together, focusing on its core purpose and what makes it significant.

What is RAG, and Why Does It Matter?

At its core, Retrieval-Augmented Generation (RAG) bridges the gap between generative language models (like GPT) and retrieval systems (such as search engines or databases). While generative models are amazing at creating human-like text, they have limitations, especially when it comes to:

Providing accurate and up-to-date information.
Retaining context about niche or domain-specific topics.
Operating efficiently without consuming massive computational resources.

These limitations—and how RAG addresses them—are discussed in more detail below. In essence, RAG solves these challenges by combining the creativity of generative AI with the precision and factual accuracy of retrieval systems.

The Problem RAG Solves

While large language models (LLMs) like GPT-3 or T5 are powerful, they have inherent limitations:

1. Outdated Knowledge

LLMs are trained on a static dataset. Once trained, their knowledge is fixed and may not include the latest information or domain-specific updates.

Example:

A user asks: "What are the latest COVID-19 travel restrictions?"

The LLM might not have up-to-date information because it relies on the training data available at the time of training.

2. Lack of Specific Domain Knowledge

LLMs may not perform well in niche domains or contexts requiring detailed, specialized information.

Example:

A legal question: "What does clause 4.3 in the GDPR specify about data retention?"

The LLM may generate a response that is vague or inaccurate due to limited understanding of the specific legal context.

3. Hallucinations

LLMs can "hallucinate" facts, producing confident-sounding but incorrect or fabricated answers because they predict the most likely word sequences, rather than relying on verified sources.

Example:

A user asks: "Who discovered Pluto?"

The model may incorrectly generate a random name, even though the correct answer is Clyde Tombaugh.

4. Inefficiency in Large Knowledge Bases

Incorporating large datasets directly into the model during training is impractical.

Example:

Storing and training on an organization's entire document library can be computationally infeasible.

Embedding all possible knowledge directly into the model leads to inefficiency.

How RAG Solves These Problems

RAG overcomes these limitations by integrating retrieval systems with generative models. Here's how:

1. Dynamic and Up-to-Date Information

RAG systems retrieve relevant data from external sources, such as a document store, database, or API, at the time of querying. This allows the system to include the latest information without retraining the model.

Example:

Query: "What are the latest COVID-19 travel restrictions?"

Retrieval: Fetch the most recent government announcements or website data.

Response: Generate an accurate, up-to-date answer based on retrieved information.

2. Domain-Specific Context

RAG systems can leverage a curated knowledge base tailored to specific industries, ensuring that responses are grounded in the desired context.

Example:

Query: "What are the best practices for microservice architecture?"

Retrieval: Fetch relevant excerpts from technical documentation or whitepapers on microservices.

Response: Generate a summary or actionable recommendations using the retrieved data.

3. Grounded Responses (Reducing Hallucinations)

By using retrieval as a foundation, RAG reduces hallucination by grounding the response generation in factual, retrieved content. The model no longer relies solely on its internal knowledge but can explicitly reference external sources.

Example:

Query: "Who discovered Pluto?"

Retrieval: Access an astronomy textbook or article specifying Clyde Tombaugh.

Response: Accurately respond based on the retrieved material.

4. Efficiency and Scalability

Instead of embedding all knowledge into the model, RAG retrieves only relevant pieces of information as needed. This reduces computational load and allows the system to scale with large datasets.

Example:

A company stores thousands of internal documents in a vector database.

Instead of fine-tuning the LLM on all documents, the RAG pipeline retrieves only the 5-10 most relevant documents for the query, ensuring efficient usage of resources.

Illustrative Example of RAG in Action

Query: "What are the benefits of solar panels?"

Retrieval: The retriever fetches excerpts from relevant documents:
- "Solar panels reduce electricity bills by converting sunlight into energy."
- "They help in reducing carbon footprints."
Generation: The generative model processes the query and retrieved data to create an informed response:
- "Solar panels offer several benefits, including reduced electricity bills and a smaller carbon footprint, by converting sunlight into energy."

Applications of RAG

Customer Support: Quickly retrieve and summarize relevant support documents to address customer queries.
Search-Driven Content Generation: Enhance search engines with conversational abilities grounded in real data.
Legal and Financial Assistance: Provide detailed, grounded answers based on legal documents or financial reports.
Medical Advice: Answer medical queries based on the latest research or medical guidelines.
Research Assistance: Summarize and contextualize scientific articles for researchers.

Why RAG is Transformative

Adaptability: Can be updated in real-time without retraining.
Customizability: Tailored to specific domains or datasets.
Efficiency: Reduces computational cost compared to embedding all data in the model.

In the next part of this post, I’ll delve deeper into how RAG works, its components, and share insights from my own exploration. Feel free to share your thoughts—how do you approach learning new technologies? Let’s start a conversation! 😊

The History and Purpose of Node.js: Revolutionizing Server-Side Programming

Amir Ehsan Ahmadzadeh — Thu, 05 Dec 2024 09:32:02 +0000

The History and Purpose of Node.js: Revolutionizing Server-Side Programming

From Simple Web Pages to Complex Systems

The web of the early 1990s was a simpler place. Static HTML pages dominated the internet, and user interactions were limited to clicking hyperlinks. However, as the web matured, user expectations changed. Websites evolved into full-fledged applications capable of handling complex tasks like online shopping, social networking, and real-time communication.

This shift brought unprecedented challenges for web servers and developers alike:

Increased Traffic: Modern applications needed to handle thousands, if not millions, of simultaneous users.
Dynamic Content: Static pages were no longer enough. Servers were expected to generate dynamic responses, pulling data from databases and external APIs in real-time.
Real-time Interaction: The rise of real-time applications like chat systems, collaborative tools, and live gaming demanded low latency and high concurrency.

The Problem with Traditional Server Architectures

Traditional server architectures struggled to keep up with these demands. For example:

Blocking I/O Operations: In conventional server models, operations like reading a file or querying a database would block the server thread, leaving it idle until the task was complete. This inefficiency reduced the server’s ability to handle multiple requests.
Thread-based Concurrency: To address blocking issues, servers like Apache relied on spawning threads for each incoming request. However, threads come with significant memory and CPU overhead, limiting the scalability of this approach.

The limitations of these architectures became increasingly evident as developers tried to build more interactive, real-time systems. The need for a new paradigm—one that could handle thousands of simultaneous connections without being bogged down by blocking operations—was clear.

Node.js: A Game-Changing Solution

In 2009, a software engineer named Ryan Dahl introduced Node.js, a framework that promised to revolutionize server-side programming. By combining an event-driven, non-blocking architecture with the power of JavaScript, Node.js became the tool that many modern web applications desperately needed.

But why did Dahl choose JavaScript, a language that had primarily been used for client-side scripting? To understand this decision and why Node.js was groundbreaking, we need to explore its design philosophy and the problems it set out to solve.

Why JavaScript? The Choice That Changed the Game

Ryan Dahl’s decision to use JavaScript as the foundation for Node.js was both bold and forward-thinking. Here’s why:

JavaScript Everywhere: By 2009, JavaScript was already the dominant language for client-side programming. Using it on the server allowed developers to write both front-end and back-end code in the same language, reducing complexity and enabling easier collaboration.
Event-Driven Nature: JavaScript, through its use in browsers, was already designed to handle asynchronous, event-driven programming. This made it a natural fit for a non-blocking server environment.
V8 Engine: Google’s V8 engine, which powered JavaScript in the Chrome browser, provided a fast and efficient runtime that could handle heavy workloads. Node.js leveraged this engine to deliver exceptional performance.

Node.js and the Event-Driven Revolution

Node.js wasn’t just a framework; it was a rethinking of how web servers should work. Instead of blocking operations and using threads to manage concurrency, Node.js adopted an event loop—a single-threaded mechanism that could handle multiple tasks asynchronously. This allowed it to serve thousands of concurrent connections without the overhead of traditional thread-based systems.

Let’s dive deeper into the core principles of Node.js to see how it handles modern web development’s toughest challenges.

Introduction: The Problem with Traditional Web Servers

In the early 2000s, web development was rapidly evolving. Applications were becoming more dynamic, interactive, and resource-intensive. However, traditional web servers like Apache faced challenges in handling the growing demands of modern applications:

Blocking I/O Operations: In most traditional server models, an incoming request would block the server’s thread while waiting for an I/O operation, such as reading from a database or accessing a file system, to complete. This inefficiency made it difficult to scale applications that required frequent or simultaneous I/O operations.
Thread-based Concurrency: Traditional server models often relied on thread-based concurrency. While threads enable servers to handle multiple requests concurrently, they come with significant overhead in memory and CPU usage, limiting scalability.
The Rising Demand for Real-time Applications: With the growth of real-time applications like chat systems, online gaming, and live collaboration tools, the need for a more efficient, non-blocking architecture became apparent.

Enter Node.js: A Solution Born from Necessity

In 2009, Ryan Dahl, a software engineer, introduced Node.js to address these limitations. Dahl sought to build a framework capable of handling a large number of simultaneous connections efficiently, without the overhead associated with threads.

Why JavaScript?

One of Dahl's most pivotal decisions was to use JavaScript as the programming language for Node.js. Here’s why:

Ubiquity of JavaScript: By 2009, JavaScript had already become the lingua franca of web development, thanks to its dominance on the client side. Using JavaScript for server-side programming meant developers could work on both ends of an application using a single language.
Event-driven Nature: JavaScript’s event-driven programming paradigm, popularized by browsers, was a perfect fit for asynchronous, non-blocking server operations.
V8 Engine: Google’s V8 engine, developed for Chrome, provided a high-performance runtime for JavaScript. Dahl leveraged V8’s speed and efficiency to build a fast, lightweight server framework.

Alternatives Considered

Before Node.js, developers relied on various technologies for building scalable web servers:

Ruby on Rails and PHP: These frameworks used synchronous, blocking I/O models and thread-based concurrency.
Python with Twisted: While Twisted provided asynchronous programming capabilities, it lacked the simplicity and performance optimization that Node.js offered.
Java (e.g., Netty): Java frameworks supported non-blocking I/O, but they came with a steep learning curve and more complexity compared to Node.js.

Core Concepts of Node.js

1. I/O-Bound vs. CPU-Bound Tasks

To understand Node.js’s significance, it’s essential to differentiate between:

I/O-bound tasks: These involve waiting for data input or output, such as reading a file, querying a database, or fetching a remote API response. These tasks are often the bottleneck in traditional server architectures.
CPU-bound tasks: These involve intensive computations, such as image processing, data encryption, or machine learning model inference.

Node.js excels at handling I/O-bound tasks due to its non-blocking, event-driven architecture. However, it is less suited for CPU-bound tasks, which can monopolize the single-threaded event loop.

2. The Asynchronous Approach

The cornerstone of Node.js is its asynchronous programming model, which allows the server to handle multiple operations concurrently without waiting for any single task to complete. This is achieved through:

Callbacks: Functions that are executed once an operation completes.
Promises and async/await: Modern abstractions for managing asynchronous operations, introduced in later versions of JavaScript.

3. Event Loop and Non-Blocking I/O

The event loop is the heart of Node.js. It allows the server to offload time-consuming operations (like file access or database queries) to the system’s underlying I/O mechanisms while continuing to process other requests. Once the operation completes, the event loop picks up the result and executes the appropriate callback.

The Rise of Node.js: Use Cases and Ecosystem

Ideal Use Cases

Node.js has become a staple for applications that require:

Real-time interaction (e.g., chat applications, online multiplayer games).
High concurrency with minimal resource usage (e.g., APIs, microservices).
Streaming capabilities (e.g., media streaming platforms).

NPM: The Node.js Package Manager

Node.js's success is closely tied to NPM, its package ecosystem. With thousands of modules readily available, developers can easily add functionality like authentication, data validation, or web frameworks (e.g., Express.js) to their projects.

Node.js emerged as a response to the limitations of traditional server models, bringing an event-driven, asynchronous approach to server-side programming. By leveraging JavaScript and Google’s V8 engine, Ryan Dahl created a framework that bridged the gap between client and server, enabling a new generation of scalable, real-time web applications.

Today, Node.js remains a cornerstone of modern web development, empowering developers to build efficient, high-performing applications that meet the demands of an ever-connected world.

DEV Community: Amir Ehsan Ahmadzadeh

NestJS Fundamentals Part 1: Modularity in NestJS

Table of Contents

What is the Module Decorator?

Inputs of the Module Decorator

Providers

Controllers

Imports

Exports

Global

Scope

Practical Example: A Modular NestJS Application

Step 1: Define a Shared Provider

Step 2: Create and Export a Module

Step 3: Import the Module and Use the Provider

FAQs About NestJS Modules

1. What is the purpose of modularity in NestJS?

2. How do I decide what should go into a module?

3. What’s the difference between providers, exports, and imports?

4. When should I use global: true for a module?

5. How does the scope of providers affect their lifecycle?

6. Can I import the same module into multiple other modules?

7. How do I handle circular dependencies between modules?

8. How do I test a module in isolation?

9. How do shared modules work in NestJS?

10. How should I organize modules in a large NestJS application?

Breaking Down Dependency Inversion, IoC, and DI

1. Dependency Inversion Principle (DIP)

What Does This Mean?

Without DIP

Python Example

TypeScript Example

With DIP

Python Example

TypeScript Example

Benefits of DIP

2. Inversion of Control (IoC)

Without IoC

Python Example: Without IoC

TypeScript Example: Without IoC

With IoC

Python Example: With IoC

TypeScript Example: With IoC

Benefits of IoC

3. Dependency Injection (DI)

Python Example: DI Framework

TypeScript Example: DI Framework

Benefits of DI

Why 'this' in JavaScript Differs from Other OOP Languages

1. Global Context

Non-Strict Mode:

Strict Mode:

2. Inside a Function

Regular Function:

3. As a Method of an Object

4. Arrow Functions

5. In a Constructor

6. Explicit Binding (call, apply, bind)

call and apply:

bind:

7. In an Event Listener

Regular Function:

Arrow Function:

8. Inside setTimeout or setInterval

Regular Function:

Arrow Function:

9. In Classes

10. Losing Context (Method Extraction)

Solutions:

11. In new Keyword Usage

Summary

Why Use Getters and Setters?!

What Are Getters and Setters?

Why Not Access Attributes Directly?

Validation and Control

Read-Only Properties

Future-Proofing

Lazy Computation

Benefits of Using Getters and Setters

What Do You Think?

3. What’s the difference between `providers`, `exports`, and `imports`?

4. When should I use `global: true` for a module?

5. How does the `scope` of providers affect their lifecycle?

6. Explicit Binding (`call`, `apply`, `bind`)

`call` and `apply`:

`bind`:

8. Inside `setTimeout` or `setInterval`

11. In `new` Keyword Usage