DEV Community: Geampiere Jaramillo

SQL vs NoSQL: Which one to choose for your next project?

Geampiere Jaramillo — Thu, 16 Apr 2026 14:56:25 +0000

When it comes to databases, two of the most popular options are SQL (Structured Query Language) and NoSQL (Not Only SQL). Both have advantages and disadvantages, and the choice between them depends on the specific needs of your application. In this blog, we'll explore the key differences between SQL and NoSQL databases, their use cases, and how to choose the right one for your project.

What is SQL?

SQL (Structured Query Language) refers to relational databases that organize data into related tables. SQL databases are highly structured, meaning that each piece of data must follow a predefined schema with clear relationships between tables. SQL databases are known for their ability to handle complex transactions and advanced queries.

Examples of SQL databases:

MySQL
PostgreSQL
SQL Server
SQLite

Main features of SQL:

Relational Model: Data is organized into tables with rows and columns. Each table can have relationships with other tables, and data can be retrieved using SQL queries.
Fixed Schema: The database schema must be defined before data is inserted, and tables must follow a predictable structure.
ACID: SQL offers ACID transactions (Atomicity, Consistency, Isolation, Durability), meaning that database operations are safe and reliable.
Complex Queries: SQL databases allow for complex queries using joins, subqueries, aggregations, and other operations.

SQL Use Cases:

Enterprise applications requiring high consistency and transactions.
Banking systems where data integrity is crucial.
Management applications that require complex relationships between data (e.g., inventory management systems, ERPs).
Applications that require regulatory compliance (such as GDPR, HIPAA) and need to maintain data integrity and control.

What is NoSQL?

NoSQL (Not Only SQL) refers to non-relational databases that offer greater flexibility in data storage and querying. Unlike SQL databases, NoSQL does not use a rigid schema or relationships between tables. Instead, it focuses on storing data in documents, key-value pairs, columns, or graphs.

Examples of NoSQL databases:

MongoDB (document-oriented)
Redis (key-value)
Cassandra (column-based)
Neo4j (graph-based)

Main features of NoSQL:

Flexible Data Model: NoSQL allows for the storage of unstructured or semi-structured data. Documents can have different fields without adhering to a fixed schema.
Horizontal Scalability: NoSQL databases are designed to scale horizontally, meaning they can be distributed across multiple servers to handle large volumes of data.
High Availability: NoSQL often employs replication and partitioning techniques to ensure data is available even when some nodes fail.
Eventual Consistency: Instead of guaranteeing strong consistency like SQL databases, NoSQL typically opts for eventual consistency, meaning that data may not be fully synchronized across all database nodes at any given time.

NoSQL Use Cases:

Real-time web applications, such as instant messaging or push notifications.
Big Data and real-time analytics of large volumes of unstructured data (e.g., logs, IoT sensors).
Social networks and content platforms that require scalability and flexibility in data storage.
Distributed and high-availability systems that need rapid failure recovery.

Diferencias clave entre SQL y NoSQL

When to choose SQL?

You should choose an SQL database when your application:

Requires data integrity and ACID-compliant transactions (e.g., financial or banking systems).
Has a well-defined data structure with clear relationships between entities (users, products, orders).
Requires complex queries involving multiple tables with relationships (joins, subqueries, etc.).
Doesn't need massive horizontal scalability, but rather vertical scalability (increasing the resources of a single server).

When to choose NoSQL?

You should choose a NoSQL database when your application:

Handles large volumes of unstructured or semi-structured data, such as logs, IoT sensor data, or multimedia content.
Requires high horizontal scalability, as NoSQL databases are designed to be distributed and handle large amounts of traffic and data.
Requires high availability and fast recovery from failures (ideal for distributed applications with large numbers of concurrent users).
Handle changing data without requiring a rigid schema or predefined structure.

Conclusion

The choice between SQL and NoSQL largely depends on the specific needs of your application. If your project requires complex transactions, data integrity, and well-defined relationships, SQL is the best option. On the other hand, if your application needs to handle large volumes of data with a flexible schema and requires horizontal scalability, NoSQL may be more suitable.

There is no one-size-fits-all answer; some applications can even benefit from a hybrid approach, using both technologies depending on the requirements of each part of the system. For example, you could use an SQL database to handle financial transactions and a NoSQL database to store logs or real-time data.

By understanding the strengths and limitations of both options, you can make a more informed decision about which type of database to use for your project.

SOLID Principles in NestJS

Geampiere Jaramillo — Wed, 28 May 2025 15:12:09 +0000

When building software, keeping your code organized and scalable is key. SOLID is a set of principles that help improve code quality. In this blog, we’ll explore how to apply SOLID in NestJS to write clean, maintainable, and extendable code.

1. Single Responsibility Principle (SRP)

Every class should have one responsibility. This makes your code easier to understand and modify.

Example in NestJS:

@Injectable()
export class UserService {
  constructor(private readonly userRepository: UserRepository) {}

  createUser(data: CreateUserDto) {
    this.userRepository.save(data); // Responsible only for user logic
  }
}

Here, UserService only handles user logic. Validation and other concerns should be separated.

2. Open/Closed Principle (OCP)

Classes should be open for extension, but closed for modification. You can add new features without changing existing code.

Example in NestJS:

interface PaymentStrategy {
  processPayment(amount: number): void;
}

class CreditCardPayment implements PaymentStrategy {
  processPayment(amount: number) {
    console.log(`Processing $${amount} via Credit Card`);
  }
}

@Injectable()
export class PaymentService {
  constructor(private paymentStrategy: PaymentStrategy) {}

  executePayment(amount: number) {
    this.paymentStrategy.processPayment(amount);
  }
}

You can add more payment methods by extending PaymentStrategy without changing PaymentService.

3. Liskov Substitution Principle (LSP)

Derived classes should be substitutable for their base classes without breaking the application.

Example in NestJS:

class Animal {
  makeSound() {}
}

class Dog extends Animal {
  makeSound() {
    console.log('Bark');
  }
}

You can use a Dog wherever an Animal is expected, without issues.

Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they don’t use. Split large interfaces into smaller, specific ones.

Example in NestJS:

interface PaymentProcessor {
  processPayment(amount: number): void;
}

class CreditCardProcessor implements PaymentProcessor {
  processPayment(amount: number) {
    console.log(`Processing $${amount} via Credit Card`);
  }
}

class PaypalProcessor implements PaymentProcessor {
  processPayment(amount: number) {
    console.log(`Processing $${amount} via PayPal`);
  }
}

Each class only implements what it needs, making the code cleaner and easier to manage.

5. Dependency Inversion Principle (DIP)

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

Example in NestJS:

interface Logger {
  log(message: string): void;
}

@Injectable()
export class MyService {
  constructor(private readonly logger: Logger) {}

  executeAction() {
    this.logger.log('Action executed');
  }
}

Here, MyService depends on the Logger interface, not a specific implementation. This improves flexibility and testability.

Conclusion

Applying SOLID principles in NestJS helps you write clean, flexible, and maintainable code. These principles make it easier to test, scale, and evolve your applications without introducing bugs.

Design Patterns in NestJS

Geampiere Jaramillo — Tue, 27 May 2025 15:41:55 +0000

When developing backend applications with NestJS, one of the biggest challenges is creating an architecture that is scalable, maintainable, and extensible. One effective way to achieve this is by using design patterns, which allow us to build more flexible, decoupled, and reusable solutions.

We will explore the most common design patterns you can implement in your NestJS applications, such as Dependency Injection, Singleton, Decorators, Strategy, and others. You will learn how to apply these patterns to improve code quality and long-term maintainability.

1. Dependency Injection (DI)

Dependency Injection is one of the core principles of NestJS. This pattern allows classes to depend on other objects without creating them explicitly, which facilitates decoupling and component reusability.

How it works in NestJS:
NestJS uses TypeScript's dependency injection container. Whenever you inject a service into another via the constructor, NestJS handles the instantiation and passes the dependency.

@Injectable()
export class MyService {
  getHello(): string {
    return 'Hello, World!';
  }
}

@Controller()
export class MyController {
  constructor(private readonly myService: MyService) {}

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

Advantages:

Decoupling: Classes do not need to know the implementation of their dependencies.
Scalability: Easy to scale and maintain when adding new dependencies.
Testing: Enables mocking services during unit testing.

2. Singleton

The Singleton pattern ensures a class has only one instance and provides a global point of access. NestJS uses this by default for services.

@Injectable()
export class MySingletonService {
  private counter = 0;

  increment() {
    this.counter++;
    return this.counter;
  }

  getCounter() {
    return this.counter;
  }
}

Advantages:

Consistency: Maintains shared state throughout the application.
Resource Management: Ideal for managing resources like database connections.

3. Decorator Pattern

Decorators are fundamental in NestJS. They allow you to add functionality to classes and methods without modifying their structure.

@Controller('users')
export class UserController {
  @Get(':id')
  getUser(@Param('id') id: string): string {
    return `User ID: ${id}`;
  }
}

Advantages:

Readability: Decorators make code more readable and organized.
Flexibility: Adds functionality in a modular way.

4. Strategy Pattern

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. It is useful when you need different behaviors for a service.

interface PaymentStrategy {
  pay(amount: number): string;
}

@Injectable()
export class CreditCardPayment implements PaymentStrategy {
  pay(amount: number): string {
    return `Paid ${amount} using Credit Card`;
  }
}

@Injectable()
export class PayPalPayment implements PaymentStrategy {
  pay(amount: number): string {
    return `Paid ${amount} using PayPal`;
  }
}

@Injectable()
export class PaymentService {
  constructor(private readonly paymentStrategy: PaymentStrategy) {}

  processPayment(amount: number): string {
    return this.paymentStrategy.pay(amount);
  }
}

Advantages:

Flexibility: Easily change system behavior without altering the structure.
Extensibility: New strategies can be added without affecting existing code.

5. Observer Pattern

The Observer pattern is useful when multiple objects need to be notified of changes in another object's state. In NestJS, this can be implemented using events.

@Injectable()
export class MyService {
  private eventEmitter = new EventEmitter();

  constructor() {
    this.eventEmitter.on('userCreated', (user) => {
      console.log('User Created:', user);
    });
  }

  createUser(user: any) {
    this.eventEmitter.emit('userCreated', user);
  }
}

Advantages:

Decoupling: Observers react to events without needing to know the subject's internal logic.
Scalability: Easy to add new functionalities by subscribing to events.

6. Command Pattern

The Command pattern encapsulates a request as an object, allowing you to parameterize clients with different requests.

class CreateUserCommand {
  constructor(public readonly username: string, public readonly email: string) {}
}

@Injectable()
export class UserService {
  executeCreateUserCommand(command: CreateUserCommand): void {
    console.log(`Creating user with username: ${command.username} and email: ${command.email}`);
  }
}

Advantages:

Decoupling: Separates the request from its execution.
Reusability: Commands can be reused in different parts of the app.

Conclusion

Design patterns are powerful tools for building scalable and maintainable backend applications. In NestJS, you can take full advantage of these patterns to structure your code in a modular, decoupled, and efficient way.

The key is to understand when and how to apply each pattern based on your project’s requirements. Start experimenting with them and see how your NestJS architecture improves.

Operators and Methods to Manipulate Arrays in JavaScript

Geampiere Jaramillo — Tue, 13 May 2025 15:29:44 +0000

When working with JavaScript—whether on the frontend with frameworks like React or on the backend with NestJS—one of the most common data structures is the array. Arrays allow us to store collections of data and offer a wide range of operators and methods to manipulate them efficiently.

In this article, we'll explore the main operators and methods you can use with arrays to transform, filter, combine, and analyze information.

📌 What Is an Array?

An array in JavaScript is an ordered collection of items. It can contain any type of data: numbers, strings, objects, or even other arrays.

const numbers = [1, 2, 3, 4, 5];
const mixed = [1, 'text', true, null, [6, 7]];

🧹 Useful Operators for Arrays

1. Spread Operator (...)

Allows cloning or combining arrays in a very readable way.

const a = [1, 2];
const b = [3, 4];
const combined = [...a, ...b]; // [1, 2, 3, 4]

2. Destructuring

Extracts individual elements from an array easily.

const [first, second] = [10, 20, 30]; // first = 10, second = 20

🔄 Common Methods to Manipulate Arrays

🔹 Mutation Methods (modify the original array)

Method	Description
`push()`	Adds elements to the end.
`pop()`	Removes the last element.
`shift()`	Removes the first element.
`unshift()`	Adds elements to the beginning.
`splice()`	Adds/removes elements at a position.
`sort()`	Sorts the array.
`reverse()`	Reverses the array order.

const fruits = ['apple', 'banana'];
fruits.push('orange'); // ['apple', 'banana', 'orange']
fruits.splice(1, 1, 'pear'); // ['apple', 'pear', 'orange']

🔹 Iteration & Transformation Methods

Method	Primary Use
`forEach()`	Executes a function for each element.
`map()`	Transforms elements and returns a new array.
`filter()`	Returns elements that meet a condition.
`reduce()`	Reduces array to a single value.
`find()`	Returns the first matching element.
`some()`	Checks if some elements match a condition.
`every()`	Checks if all elements match a condition.

const numbers = [1, 2, 3, 4, 5];

const doubled = numbers.map(n => n * 2); // [2, 4, 6, 8, 10]
const evens = numbers.filter(n => n % 2 === 0); // [2, 4]
const total = numbers.reduce((acc, n) => acc + n, 0); // 15

🔹 Search Methods

const letters = ['a', 'b', 'c'];
letters.includes('b');  // true
letters.indexOf('c');   // 2

🔹 Conversion Methods

const words = ['hello', 'world'];
words.join(' ');  // 'hello world'

🧠 Tip: Non-Destructive vs Destructive Methods

Non-destructive: map(), filter(), slice(), concat(), etc.
Destructive: push(), pop(), splice(), sort(), etc.

Prefer non-destructive methods when aiming for immutability—a key principle in functional programming and modern frameworks.

🔪 Bonus: Advanced Methods

flat() and flatMap()

const nested = [1, [2, 3], [4, 5]];
nested.flat(); // [1, 2, 3, 4, 5]

const duplicated = [1, 2, 3].flatMap(n => [n, n]); // [1, 1, 2, 2, 3, 3]

🚀 Conclusion

Mastering array manipulation is essential for any JavaScript developer. Whether you're building APIs with NestJS or transforming data in the frontend, understanding these operators and methods will help you write cleaner, more efficient code.

Do you have a favorite array method or a cool tip? Let me know in the comments!

Method Binding in NestJS: What It Is and When to Use It

Geampiere Jaramillo — Thu, 08 May 2025 15:03:34 +0000

In NestJS development—a Node.js framework focused on modular architecture and class-based design—one concept that can confuse developers is method binding. This blog post explains what it is, when it matters, and how to handle it properly.

What Is Method Binding?

In JavaScript and TypeScript, the value of this inside a method can change depending on how and where the method is called. Method binding refers to ensuring that this inside the method always points to the correct class instance, especially when the method is passed as a callback.

Classic Problem: Callback with `setInterval`


@Injectable()
export class MyService {
  private count = 0;

  increment() {
    this.count++;
    console.log('Count:', this.count);
  }

  start() {
    setInterval(this.increment, 1000); // 'this' is undefined here
  }
}

In this example, this.increment loses its class context when passed as a callback to setInterval, resulting in an error or unexpected behavior.

Common Solutions in NestJS

1. Use bind(this)

start() {
  setInterval(this.increment.bind(this), 1000);
}

bind ensures that this inside increment continues to refer to the MyService instance.

2. Use Arrow Functions

increment = () => {
  this.count++;
  console.log('Count:', this.count);
};

Arrow functions do not have their own this; they inherit it from their creation context, which avoids the problem without needing bind.

When You Need to Bind Methods

When passing methods as callbacks to async functions like setTimeout, setInterval, or event handlers.
When using methods in custom listeners.
When using methods as middleware or hooks where context is lost.

Best Practices

In services or controllers, consider using arrow functions to preserve this context.
Use bind(this) if you need to pass a method as a callback and prefer not to redefine it.
Avoid overusing arrow functions in classes if you rely on inheritance or unit testing that depends on traditional methods.

Conclusion

NestJS makes dependency and state management easy, but the behavior of this in JavaScript still needs attention. Understanding and properly applying method binding helps avoid subtle bugs and leads to cleaner, more maintainable code. Whether through bind(this) or arrow functions, choosing the right strategy depends on your application's context and design.

Mastering Functional Programming: Immutability, Composition, Pure and Arrow Functions

Geampiere Jaramillo — Wed, 07 May 2025 16:02:48 +0000

Functional programming has gained traction in modern development due to its ability to produce more predictable, modular, and testable code. In this post, we explore four fundamental principles: immutability, function composition, pure functions, and arrow functions.

🧊 Immutability: Protect Your State

Immutability means that once a value is created, it cannot be changed. Instead of mutating data, we return new versions with the desired updates.

✅ Why is it useful?

Prevents unpredictable side effects
Easier debugging and testing
Ideal for concurrent environments (like React or Redux)

❌ Mutable example:

const user = { name: 'Alice', age: 25 };
user.age = 26; // Mutation

✅ Immutable example:

const user = { name: 'Alice', age: 25 };
const updatedUser = { ...user, age: 26 }; // New copy with changes

🔁 Function Composition: Chain Your Logic

Function composition means combining small, reusable functions to build more complex logic.

const trim = str => str.trim();
const toUpper = str => str.toUpperCase();

const cleanAndCapitalize = str => toUpper(trim(str));

cleanAndCapitalize("  hello  "); // "HELLO"

Or dynamically compose using a helper:

const compose = (...fns) => x => fns.reduce((acc, fn) => fn(acc), x);

const cleanAndCapitalize = compose(trim, toUpper);

📌 Benefit: cleaner, modular, and easily testable code.

🦼 Pure Functions: No Surprises

A pure function follows two rules:

Always returns the same output for the same inputs
Has no side effects (doesn't modify external variables or interact with I/O)

✅ Pure function:

const add = (a, b) => a + b;

❌ Impure function:

let counter = 0;
const increment = () => ++counter;

Advantages:

Easier to test
Fewer hidden dependencies
Can be memoized or cached

🌽 Arrow Functions: Elegant and Contextual

Arrow functions (=>) offer a concise way to declare functions in JavaScript and TypeScript. They also don’t have their own this, making them perfect for callbacks.

✅ Simple example:

const double = n => n * 2;

🧠 Implicit return:

const sum = (a, b) => a + b;

🎯 this behavior:

function Timer() {
  this.seconds = 0;

  setInterval(() => {
    this.seconds++;
    console.log(this.seconds);
  }, 1000); // `this` works correctly
}

🧹 Conclusion

Adopting functional principles like immutability, composition, and pure functions (along with arrow functions) helps you write more declarative, maintainable, and robust code. These ideas are especially powerful in modern frameworks like React, NestJS, or Redux, where predictable data flow is crucial.

Test-Driven Development (TDD) and Domain-Driven Design (DDD): The Perfect Duo for Robust NestJS Applications

Geampiere Jaramillo — Tue, 06 May 2025 14:37:53 +0000

When working on complex applications, especially in the backend world, keeping domain clarity and code quality is a constant challenge. That's where DDD (Domain-Driven Design) and TDD (Test-Driven Development) shine as complementary approaches. In this article, I'll show you how to combine them in a project using NestJS with modern best practices.

🧠 What is DDD?

Domain-Driven Design is a software development philosophy that focuses on the business domain. Instead of forcing the domain to fit the code, we adapt the code to represent the domain.

Key components of DDD:

Entities: Objects with identity (e.g., a User).
Value Objects: Objects without identity, defined by their attributes (Email, Money).
Aggregates: Consistency boundaries grouping related entities.
Repositories: Abstractions for accessing aggregates.
Domain/Application Services.

🔀 What is TDD?

Test-Driven Development is a software development practice following this cycle:

Write a failing test (Red).
Write the minimum code to pass it (Green).
Refactor the code (Refactor).

TDD not only ensures your code works, but it also forces clean API and logic design from the beginning.

🤝 How Do DDD and TDD Complement Each Other?

DDD helps define what needs to be built and how to model it.
TDD ensures what is built is correct, testable, and maintainable.

With DDD, you design a rich domain model; with TDD, you continuously validate its expected behavior.

🛠️ Example: Changing a User's Name in NestJS using DDD + TDD

Step 1: Write the Test First (TDD)

// change-user-name.use-case.spec.ts

describe('ChangeUserNameUseCase', () => {
  it('should change the user name', async () => {
    const user = new User('1', 'John', 'john@example.com');
    const userRepository = {
      findById: jest.fn().mockResolvedValue(user),
      save: jest.fn(),
    };

    const useCase = new ChangeUserNameUseCase(userRepository);
    await useCase.execute('1', 'Jane');

    expect(user.name).toBe('Jane');
    expect(userRepository.save).toHaveBeenCalledWith(user);
  });
});

Step 2: Domain Logic with DDD

// user.entity.ts
export class User {
  constructor(
    public readonly id: string,
    public name: string,
    public readonly email: string
  ) {}

  changeName(newName: string) {
    if (!newName) throw new Error('Name cannot be empty');
    this.name = newName;
  }
}

Step 3: Application Layer Use Case

// change-user-name.use-case.ts

export class ChangeUserNameUseCase {
  constructor(private readonly userRepository: UserRepository) {}

  async execute(userId: string, newName: string) {
    const user = await this.userRepository.findById(userId);
    user.changeName(newName);
    await this.userRepository.save(user);
  }
}

🧹 Benefits of Combining DDD + TDD

Testable domain models from day one.
Better interface design thanks to the "test-first" approach.
High cohesion in business logic.
Low coupling between layers (presentation, application, domain, infrastructure).

🧼 Best Practices

✅ Use interfaces in repositories to decouple infrastructure from domain.
✅ Keep Value Objects immutable.
✅ Use case tests are more valuable than controller tests.
✅ Avoid domain logic in controllers: delegate to use cases.
✅ If a business rule changes, only the aggregate should be updated.

🏁 Conclusion

Adopting DDD to model your domain properly and using TDD to continuously validate its behavior not only improves code quality but also makes your app more scalable and maintainable. In NestJS, this combination is natural thanks to its modular architecture and built-in testing support.

Building a complex or critical product? Then DDD + TDD isn't optional it's essential.

Mastering Microservices Patterns: Circuit Breaker, Fallback, Bulkhead, Saga, and CQRS

Geampiere Jaramillo — Mon, 05 May 2025 15:20:51 +0000

In the world of microservices, we often face challenges like availability, resilience, scalability, and data consistency. To tackle these issues, several architectural patterns help us build more reliable and robust systems. In this article, we’ll explore five essential microservices patterns: Circuit Breaker, Fallback, Bulkhead, Saga, and CQRS.

Circuit Breaker: Protecting the system from failure

When a microservice starts failing repeatedly—due to high latency or downtime—the Circuit Breaker pattern acts like an electrical fuse.
Instead of continuing to make failing calls, the circuit "opens" and temporarily blocks new requests to the failing service. This protects the rest of the system from cascading failures and gives the faulty service time to recover.

Real-world use case:
If a payment service becomes unresponsive, the order service can open the circuit and avoid waiting on it, improving system stability.

Popular tools: Resilience4j, Hystrix, NestJS with resiliency libraries.

Fallback: Always have a plan B

Fallback is the natural companion to Circuit Breaker. It defines an alternative response when a service call fails.
Instead of showing an error to the user, you provide a safe, degraded but usable experience.

Example:
If a product recommendation service is down, show trending or popular products instead.

Benefit:
Improves resilience and ensures a smoother user experience during failures.

Bulkhead: Isolate to survive

The Bulkhead pattern, inspired by ship compartments, isolates parts of the system to contain failures.
In microservices, it means isolating resources (like threads, memory, or connections) so that a failure in one component doesn't bring down the entire system.

Practical example:
Separate the HTTP connection pool for critical services (like payments) and non-critical ones (like email notifications).
This way, if notifications are overloaded, they won’t impact core functionality.

Saga: Coordinating distributed transactions

When a business process spans multiple microservices, the Saga pattern helps coordinate actions in a decentralized and asynchronous way.

Instead of relying on expensive distributed transactions, each service performs its action and, in case of failure, executes compensating actions to undo previous steps.

Typical use case:
During a purchase process:

Reserve product stock.
Charge the customer.
Confirm the order.

If the payment fails, the system triggers a compensation to release the reserved stock.

Two styles of Sagas:

Orchestrated: A central service directs the flow.
Choreographed: Services react to events in a distributed manner.

CQRS: Divide and conquer

CQRS (Command Query Responsibility Segregation) promotes the separation of read and write responsibilities within an application.

Why is this helpful?

Reads and writes often have different performance and scaling requirements.
You can optimize and scale them independently.
It offers more flexibility for high-load systems.

Example scenario:
In an e-commerce platform:

Product listings and order history are handled by a read model (possibly using a cache like Redis).
Actions like placing an order or updating stock are handled by a write model (using a transactional DB like PostgreSQL).

Benefits:

Better performance and user experience.
Easier scaling for high-traffic endpoints.
More flexible architecture.

Caveat:
CQRS adds complexity, so it's most useful in systems with high query loads or complex business logic on writes.

Final Thoughts

By using patterns like Circuit Breaker, Fallback, Bulkhead, Saga, and CQRS, we can build microservices that are more resilient, fault-tolerant, and prepared for the real-world challenges of distributed systems.

Each pattern serves a specific purpose:

Circuit Breaker prevents cascading failures.
Fallback ensures graceful degradation.
Bulkhead isolates failures.
Saga coordinates long-running processes.
CQRS separates concerns for better optimization.

Understanding and applying these patterns will help you create microservice architectures that don’t just work—but thrive in production.

Queues vs Topics

Geampiere Jaramillo — Fri, 02 May 2025 16:02:21 +0000

In the world of software development—especially with distributed systems and microservices—asynchronous messaging has become essential for building scalable and resilient applications. Two of the most common messaging patterns are queues and topics. While they might sound similar, their behavior and use cases are quite different.

In this post, I’ll explain what they are, how they differ, and when to use each one.

What Is a Queue?

A queue follows a point-to-point communication model: messages are sent by a producer and consumed by only one consumer. Once a message is processed, it is removed from the queue.

Key characteristics:

Each message is processed by one and only one consumer.
Guarantees single delivery of each message.
Useful for load balancing between multiple consumers.
Maintains message order (FIFO – First In, First Out).

When to use queues:

Background processing.
Order or job handling systems.
Distributing workload across workers.

What Is a Topic?

A topic uses a publish-subscribe (pub/sub) model. In this case, a message published to a topic is received by all subscribers.

Key characteristics:

Multiple consumers receive the same message.
Full decoupling between producers and consumers.
Enables more flexible, event-driven architectures.
Subscribers can process messages at their own pace.

When to use topics:

Real-time notifications or broadcasting.
Event-driven systems.
Integrations where multiple services must react to the same event.

Key Differences Between Queues and Topics

Feature	Queue	Topic
Communication model	Point-to-Point	Publish-Subscribe
Message distribution	One consumer per message	All subscribers receive the message
Delivery guarantee	Single delivery	One copy per subscriber
Main purpose	Load balancing	Broadcasting messages
Use cases	Job processing, task queues	Notifications, event sourcing, integration

RabbitMQ and Kafka: How They Implement It

In RabbitMQ, queues are used for point-to-point messaging, and topic exchanges are used for pub/sub.

In Kafka, everything is based on topics, but partitions can help simulate queue-like behavior.

Conclusion

Both queues and topics are fundamental in modern systems. Choosing between them depends on your business and technical needs:

Use queues when each task should be processed once, by only one worker.
Use topics when a message must be delivered to multiple subscribers.

Mastering both models will help you design systems that are scalable, resilient, and easy to maintain.

Building Flexible Applications with Hexagonal and Event-Driven Architecture in NestJS

Geampiere Jaramillo — Thu, 01 May 2025 14:48:07 +0000

In modern software development, one of the biggest challenges is keeping code clean, scalable, and loosely coupled.
NestJS, thanks to its modular design and pattern-friendly structure, is a powerful framework for building robust systems using Hexagonal Architecture and Event-Driven Architecture.
I’ll explain what these architectures are, why they matter, and how you can apply them using NestJS.

🧩 What Is Hexagonal Architecture?

Also known as Ports and Adapters, Hexagonal Architecture organizes code to separate core business logic from external concerns like databases, APIs, or messaging systems.

🔧 Key Concepts:

Domain: The heart of your business logic.
Ports: Interfaces that connect the domain to the outside world.
Adapters: Implementations of the ports (e.g., HTTP controllers, database services, or message brokers).

🎯 Benefits:

Decoupling: Infrastructure changes (like switching databases) don’t affect the business logic.
Testability: Core logic can be tested without involving real infrastructure.
Independent evolution: You can update adapters without altering the domain code.

In NestJS, Hexagonal Architecture fits naturally with modules. The domain is implemented as pure services, ports as TypeScript interfaces, and adapters as infrastructure-specific providers.

🔄 What Is Event-Driven Architecture?

Event-Driven Architecture (EDA) enables components of a system to communicate by emitting and listening to events, rather than calling each other directly.

In this model:
Components emit events when something important happens.

Other components listen and react to those events asynchronously.

A simple example:
When a user signs up, a user.created event is emitted. Services like “send welcome email” or “log metrics” can react without the main service knowing about them.

🎯 Benefits:

Loose coupling: Services are not tightly bound to each other.
Scalability: You can add new consumers of an event without touching the producers.
Resilience: Using queues (Kafka, RabbitMQ), events can be persisted and processed even if services are temporarily down.

In NestJS, EDA is implemented using:

EventEmitterModule for in-memory internal events.
@nestjs/microservices module to work with external brokers like Kafka or RabbitMQ.

🚀 Combining Hexagonal and Event-Driven Architecture in NestJS

Using both Hexagonal Architecture and Event-Driven Architecture gives you systems that are:

Highly modular
Decoupled both from infrastructure and from internal processes
Easier to maintain, evolve, and scale

A Typical Strategy in NestJS:

Your domain layer triggers domain events like UserCreatedEvent.
An infrastructure adapter (e.g., a Kafka publisher) publishes that event.
Other services consume the event and act independently.

This decouples logic not only between modules, but also across your entire system.

🛠️ Best Practices and Tools

While using these architectures in NestJS, keep these practices in mind:

Use DTOs to validate input.
Consider Event Sourcing or Outbox Pattern for consistent event publishing.
Implement global error handling using NestJS filters and custom exceptions.
Focus tests on the domain using mocked ports.
Design for idempotency when processing events to avoid duplicate side effects.
Use observability tools (logs, tracing) for debugging event flows.

For infrastructure-based EDA, tools like Kafka, RabbitMQ, and NATS are great options, and NestJS integrates well with all of them.

📚 Conclusion

By combining Hexagonal Architecture and Event-Driven Architecture in NestJS, you can build applications that are:

Clean
Loosely coupled
Scalable
Resilient

These patterns allow your system to grow and adapt over time without becoming unmanageable.

Are you already applying these architectures in your projects? 🚀

How to Manage Memory and Avoid Leaks in NestJS Applications

Geampiere Jaramillo — Mon, 28 Apr 2025 20:32:14 +0000

Efficient memory management is crucial for building scalable and reliable applications, especially when working with Node.js and NestJS. Poor resource management can lead to memory leaks, degraded performance, and even system crashes.

We'll explore best practices to avoid memory leaks and the tools you can use to monitor and optimize resource usage in NestJS applications.

📚 What is a Memory Leak?

A memory leak occurs when an application keeps references to objects that are no longer needed, preventing JavaScript’s garbage collector from freeing them. Over time, this leads to growing memory usage, performance degradation, and potential crashes.

🛠️ Best Practices to Manage Memory in NestJS

1. Avoid Circular References

When two or more objects refer to each other, circular references are created, making it harder for the garbage collector to clean them up.
✅ Use patterns like WeakMap for weak references when needed.

const wm = new WeakMap();
let obj = { name: 'Test' };
wm.set(obj, 'some value');
obj = null; // Now it can be garbage collected

2. Manually Release Resources

Always close database connections, sockets, and streams when they are no longer needed.

await this.databaseConnection.close();

In NestJS, use lifecycle hooks like OnModuleDestroy and OnApplicationShutdown to automatically release resources:

@Injectable()
export class AppService implements OnApplicationShutdown {
  async onApplicationShutdown(signal: string) {
    await this.databaseConnection.close();
  }
}

3. Properly Manage Event Listeners

Unremoved event listeners can cause memory leaks.

✅ Always removeListener or off listeners you no longer need:

this.eventEmitter.off('orderCreated', this.handleOrderCreated);

4. Control the Growth of Collections

Avoid storing unnecessary data in arrays or maps.
Clear them when they are no longer needed:

this.largeArray = [];

5. Use Streams for Large Files

When handling large files, use streams instead of loading the entire content into memory.

const stream = fs.createReadStream('bigfile.txt');
stream.pipe(process.stdout);

6. Monitor and Optimize Dependencies

Some third-party libraries can introduce memory leaks.
✅ Regularly review, audit, and update your project dependencies.

🔥 Tools to Detect and Prevent Memory Leaks

Node.js Inspector + Chrome DevTools

Start your app with --inspect to debug in Chrome:

node --inspect dist/main.js

From chrome://inspect, you can:

Take heap snapshots.
Monitor object growth.
Analyze memory usage.

Clinic.js

A powerful performance analysis suite:

npm install -g clinic
clinic doctor -- node dist/main.js

Generates visual reports about memory, CPU, and event loop behavior.

Heapdump

Capture memory snapshots (.heapsnapshot) for deeper analysis.

npm install heapdump

import * as heapdump from 'heapdump';
heapdump.writeSnapshot('/path/to/dump.heapsnapshot');

You can open these snapshots in Chrome DevTools to find memory leaks.

Memwatch-Next

Real-time memory leak detection:

npm install memwatch-next

import * as memwatch from 'memwatch-next';
memwatch.on('leak', (info) => {
  console.error('Leak detected:', info);
});

Prometheus + Grafana

For production-grade monitoring:

Use prom-client to expose memory metrics.
Visualize and set up alerts with Grafana.

npm install prom-client

const client = require('prom-client');
const collectDefaultMetrics = client.collectDefaultMetrics;

collectDefaultMetrics();

const http = require('http');
const server = http.createServer((req, res) => {
  res.setHeader('Content-Type', client.register.contentType);
  res.end(client.register.metrics());
});

server.listen(8080);

🧹 Extra Best Practices for NestJS

Use DTOs and Pipes to validate and sanitize input data.
Apply clean architecture principles like CQRS or Hexagonal Architecture.
Properly manage Singleton instances.
Avoid heavy decorators or stateful interceptors unless necessary.

✨ Conclusion

Proper memory management in a NestJS application is not optional — it's essential for building stable and scalable services.
By following best practices and leveraging the right tools, you can detect and fix memory leaks before they escalate into major problems.

Remember: In production, a memory leak doesn't just hurt your app — it can hurt your business!

Authentication using NestJS and JWT

Geampiere Jaramillo — Mon, 28 Apr 2025 15:04:32 +0000

Authentication is a fundamental pillar in web application development. I’ll explain how to handle authentication in an API built with NestJS, using JWT (JSON Web Tokens) to securely and efficiently protect our routes.

What is Authentication?

Authentication is the process of verifying that someone is who they claim to be. In web applications, this typically involves providing a username and password. If the credentials are correct, access to protected resources is granted.

Why use JWT?

JWT (JSON Web Token) is an open standard that allows information to be securely transmitted between two parties. In an API, it’s commonly used to issue a "pass" (token) to the user upon login, which can then be used to authorize future requests.

Main advantages of using JWT:

Decoupled Authentication: The server doesn’t need to store sessions in memory.
Scalability: Perfect for distributed systems or microservices.
Security: Tokens are signed and can carry securely encoded data.

How to Implement Authentication in NestJS?

1. Install Necessary Dependencies

First, install the required packages:

npm install @nestjs/jwt @nestjs/passport passport passport-local bcryptjs
npm install --save-dev @types/passport-local

2. Create the Authentication Module

Generate an AuthModule, along with its service AuthService and controller AuthController:

nest generate module auth
nest generate service auth
nest generate controller auth

3. Authentication Logic

The AuthService will validate users and generate tokens:

@Injectable()
export class AuthService {
  constructor(
    private usersService: UsersService,
    private jwtService: JwtService,
  ) {}

  async validateUser(username: string, password: string): Promise<any> {
    const user = await this.usersService.findOneByUsername(username);
    if (user && bcrypt.compareSync(password, user.password)) {
      const { password, ...result } = user;
      return result;
    }
    return null;
  }

  async login(user: any) {
    const payload = { username: user.username, sub: user.id };
    return {
      access_token: this.jwtService.sign(payload),
    };
  }
}

4. Create the Login DTO

We create a DTO (Data Transfer Object) to structure the login request:

export class LoginDto {
  username: string;
  password: string;
}

This ensures the API always receives well-formed data during login.

5. Implement the JWT Strategy

Passport requires a strategy to validate tokens. Here’s the JwtStrategy:

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor() {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      secretOrKey: process.env.JWT_SECRET,
    });
  }

  async validate(payload: any) {
    return { userId: payload.sub, username: payload.username };
  }
}

6. Protect Routes

We protect routes using guards:

@UseGuards(JwtAuthGuard)
@Get('profile')
getProfile(@Request() req) {
  return req.user;
}

The JwtAuthGuard automatically checks if a valid token is present before granting access.

Full Authentication Flow

The user sends a username and password to /auth/login.
The server validates the credentials.
If valid, the server returns a JWT.
The client stores the token (e.g., in LocalStorage).
For every protected request, the client sends the token in the Authorization header.
The backend validates the token before processing the request.

Best Practices

Encrypt passwords using strong hashing algorithms like bcrypt.
Protect your secrets used for signing JWTs (use environment variables).
Set short expiration times for access tokens.
Implement refresh tokens if you need longer user sessions.

Conclusion

Authentication with NestJS and JWT provides a modern, secure, and scalable way to protect your APIs. By combining Passport.js with NestJS, we can handle users, sessions, and permissions in a clean and efficient manner.

DEV Community: Geampiere Jaramillo

SQL vs NoSQL: Which one to choose for your next project?

What is SQL?

SQL Use Cases:

What is NoSQL?

Examples of NoSQL databases:

Main features of NoSQL:

NoSQL Use Cases:

Diferencias clave entre SQL y NoSQL

When to choose SQL?

When to choose NoSQL?

Conclusion

SOLID Principles in NestJS

1. Single Responsibility Principle (SRP)

2. Open/Closed Principle (OCP)

3. Liskov Substitution Principle (LSP)

5. Dependency Inversion Principle (DIP)

Conclusion

Design Patterns in NestJS

1. Dependency Injection (DI)

2. Singleton

3. Decorator Pattern

4. Strategy Pattern

5. Observer Pattern

6. Command Pattern

Conclusion

Operators and Methods to Manipulate Arrays in JavaScript

📌 What Is an Array?

🧹 Useful Operators for Arrays

🔄 Common Methods to Manipulate Arrays

🔹 Mutation Methods (modify the original array)

🔹 Iteration & Transformation Methods

🔹 Search Methods

🔹 Conversion Methods

🧠 Tip: Non-Destructive vs Destructive Methods

🔪 Bonus: Advanced Methods

🚀 Conclusion

Method Binding in NestJS: What It Is and When to Use It

What Is Method Binding?

Classic Problem: Callback with setInterval

Common Solutions in NestJS

When You Need to Bind Methods

Best Practices

Conclusion

Mastering Functional Programming: Immutability, Composition, Pure and Arrow Functions

🧊 Immutability: Protect Your State

🔁 Function Composition: Chain Your Logic

🦼 Pure Functions: No Surprises

🌽 Arrow Functions: Elegant and Contextual

🧹 Conclusion

Test-Driven Development (TDD) and Domain-Driven Design (DDD): The Perfect Duo for Robust NestJS Applications

🧠 What is DDD?

🔀 What is TDD?

🤝 How Do DDD and TDD Complement Each Other?

🛠️ Example: Changing a User's Name in NestJS using DDD + TDD

🧹 Benefits of Combining DDD + TDD

🧼 Best Practices

🏁 Conclusion

Mastering Microservices Patterns: Circuit Breaker, Fallback, Bulkhead, Saga, and CQRS

Circuit Breaker: Protecting the system from failure

Fallback: Always have a plan B

Bulkhead: Isolate to survive

Saga: Coordinating distributed transactions

CQRS: Divide and conquer

Why is this helpful?

Final Thoughts

Queues vs Topics

What Is a Queue?

What Is a Topic?

Key Differences Between Queues and Topics

RabbitMQ and Kafka: How They Implement It

Conclusion

Building Flexible Applications with Hexagonal and Event-Driven Architecture in NestJS

🧩 What Is Hexagonal Architecture?

🔧 Key Concepts:

🎯 Benefits:

🔄 What Is Event-Driven Architecture?

🎯 Benefits:

🚀 Combining Hexagonal and Event-Driven Architecture in NestJS

A Typical Strategy in NestJS:

Classic Problem: Callback with `setInterval`