Forem: Wallace Freitas

Pino vs. Winston: Choosing the Right Logger for Your Node.js Application

Wallace Freitas — Thu, 27 Mar 2025 13:40:20 +0000

Logging is a critical part of any Node.js application, helping developers track issues, monitor performance, and debug efficiently. Two of the most popular logging libraries in the Node.js ecosystem are Pino and Winston. While both offer powerful logging capabilities, they have distinct advantages and trade-offs.

In this article, we'll explore the advantages and disadvantages of using Pino and Winston, helping you decide which one best fits your project's needs.

Pino: A High-Performance Logger

Pino is designed for speed and low overhead, making it ideal for high-performance applications.

Advantages of Pino

→ Blazing Fast – Pino is one of the fastest logging libraries, thanks to its async logging and optimized serialization.

→ Low Overhead – Reduces performance impact, making it a great choice for high-scale applications.

→ JSON-Formatted Logs – Structured logging is built-in, making it easy to integrate with log management tools.

→ Asynchronous Logging – Uses worker threads to minimize blocking, improving application responsiveness.

→ Built-in Log Rotation – No need for external dependencies to manage log file rotation.

Disadvantages of Pino

→ Steeper Learning Curve – Its API and stream-based logging might require more effort to set up.

→ Limited Transport Support – Unlike Winston, Pino doesn’t offer built-in support for multiple transports (e.g., logging to files, databases, or external services).

→ Minimal Customization – While lightweight, it lacks some of the rich formatting options Winston provides.

Winston: A Versatile and Feature-Rich Logger

Winston is a highly configurable and modular logging library that supports multiple transports.

Advantages of Winston

→ Multi-Transport Support – Easily log to different outputs (files, databases, cloud services, etc.).

→ Highly Customizable – It offers rich formatting, custom log levels, and flexible configurations.

→ Middleware Support – Works seamlessly with Express and other frameworks.

→ Synchronous and Asynchronous Logging – Gives flexibility depending on your performance needs.

→ Community and Ecosystem – Well-documented with strong community support.

Disadvantages of Winston

→ Slower Performance – Compared to Pino, Winston is slower due to its feature-rich nature.

→ Higher Memory Usage – More complex configurations can result in slightly higher resource consumption.

→ Complex Setup – While powerful, setting up Winston for advanced use cases requires more effort than Pino.

Which One Should You Choose?

Feature	Pino 🚀	Winston 🏆
Performance	⚡ Extremely fast	🐢 Slower but flexible
Ease of Use	Requires setup effort	More intuitive
Customization	Limited formatting options	Highly customizable
Transports	Basic, needs external support	Built-in multi-transport
Middleware Support	Manual setup	Express-compatible out of the box
Best For	High-performance applications, microservices	General-purpose logging, enterprise apps

Final Recommendation

1️⃣ If you need raw speed and minimal overhead, go with Pino.

2️⃣ If you need flexibility, customization, and multiple logging outputs, Winston is the better choice.

Both libraries are excellent options, and the decision depends on your application's needs and priorities.

Setting Up PostgreSQL Replication with Docker

Wallace Freitas — Wed, 19 Mar 2025 19:59:44 +0000

In this blog post, we will walk through the process of setting up PostgreSQL replication using Docker. Replication is a critical feature for ensuring high availability and fault tolerance in database systems. By the end of this guide, you will have a primary PostgreSQL instance and a replica instance running in Docker containers, with replication configured between them.

Prerequisites

Before we begin, make sure you have the following installed on your system:

🐳 Docker
🐙 Docker Compose (optional, but recommended for managing multi-container applications)

Step 1: Create Docker Network

First, we need to create a Docker network that will allow our PostgreSQL containers to communicate with each other.

docker network create pg-network

Step 2: Run PostgreSQL Containers

Next, we will run two PostgreSQL containers: one for the primary instance and one for the replica instance.

docker run -d --name pg-primary --network=pg-network -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=postgres -e POSTGRES_DB=postgres -v pg-primary-data:/var/lib/postgresql/data -p 5432:5432 postgres
docker run -d --name pg-replica --network=pg-network -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=postgres -e POSTGRES_DB=postgres -v pg-replica-data:/var/lib/postgresql/data -p 5433:5432 postgres

Step 3: Configure the Primary Instance

We need to configure the primary PostgreSQL instance to allow replication. This involves setting several parameters in the postgresql.conf file and updating the pg_hba.conf file to allow replication connections.

Access the Primary Container

docker exec -it pg-primary bash

Update postgresql.conf

echo "wal_level = replica" >> /var/lib/postgresql/data/postgresql.conf
echo "max_wal_senders = 3" >> /var/lib/postgresql/data/postgresql.conf
echo "wal_keep_size = 64MB" >> /var/lib/postgresql/data/postgresql.conf

Update pg_hba.conf

echo "host replication all 0.0.0.0/0 md5" >> /var/lib/postgresql/data/pg_hba.conf

Restart the Primary Container

docker restart pg-primary

Step 4: Configure the Replica Instance

Now, we need to configure the replica PostgreSQL instance to connect to the primary instance and start replication.

Access the Replica Container

docker exec -it pg-replica bash

Stop PostgreSQL Service

/usr/lib/postgresql/17/bin/pg_ctl stop -D /var/lib/postgresql/data

Remove Existing Data

rm -rf /var/lib/postgresql/data/*

Perform Base Backup

/usr/lib/postgresql/17/bin/pg_basebackup -h pg-primary -D /var/lib/postgresql/data -U postgres -v -P --wal-method=stream

Update postgresql.conf

echo "primary_conninfo = 'host=pg-primary port=5432 user=postgres password=postgres'" >> /var/lib/postgresql/data/postgresql.conf

Create Standby Signal File

touch /var/lib/postgresql/data/standby.signal

Start PostgreSQL Service

/usr/lib/postgresql/17/bin/pg_ctl start -D /var/lib/postgresql/data

Conclusion

Congratulations 🥳🥳! You have successfully set up PostgreSQL replication using Docker. The primary instance is now configured to allow replication, and the replica instance is set up to replicate data from the primary instance. This setup ensures that your data is replicated in real-time, providing high availability and fault tolerance for your PostgreSQL database.

By following these steps, you can easily scale your PostgreSQL deployment and ensure that your data is always available, even in the event of a failure. Happy coding!

Object Calisthenics: Writing Better Object-Oriented Code

Wallace Freitas — Tue, 11 Mar 2025 20:07:23 +0000

Writing clear, scalable, and maintainable code is equally as crucial in the software development industry as resolving business issues. However, how can you make sure that your object-oriented programming stays organized and extensible? Object Calisthenics can help with it.

Object Calisthenics is a collection of nine guidelines that enforce better design and maintainability in order to enhance object-oriented programming (OOP) techniques. Similar to how calisthenics exercises increase muscular strength, these guidelines, which were first put forth by Jeff Bay in The ThoughtWorks Anthology, serve as exercises for producing better code.

In this article, we’ll explore:

✓ What Object Calisthenics is and why it matters.
✓ The 9 rules with practical examples in TypeScript/Node.js.
✓ How following these principles leads to better OOP design.

9 Rules of Object Calisthenics

Here’s a breakdown of each rule and a TypeScript example to illustrate how to apply them effectively.

Rule: One Level of Indentation per Method

Avoid deep nesting to improve readability and maintainability.

❌ Bad Example:

function validateUser(user: User): boolean {
  if (user) {
    if (user.age > 18) {
      if (user.hasSubscription) {
        return true;
      }
    }
  }
  return false;
}

✅ Good Example: (Refactoring with early returns)

function validateUser(user: User): boolean {
  if (!user) return false;
  if (user.age <= 18) return false;
  if (!user.hasSubscription) return false;

  return true;
}

By reducing nesting, the function becomes easier to read and understand.

Rule: Don’t Use the ELSE Keyword

Else statements often introduce unnecessary complexity and can be refactored with early returns.

❌ Bad Example:

function getDiscount(price: number, isMember: boolean): number {
  if (isMember) {
    return price * 0.9;
  } else {
    return price;
  }
}

✅ Good Example:

function getDiscount(price: number, isMember: boolean): number {
  if (isMember) return price * 0.9;
  return price;
}

This reduces cognitive load and makes the function more maintainable.

Rule: Wrap Primitives in Objects

Use value objects instead of raw primitives to enforce domain rules.

❌ Bad Example:

class Order {
  constructor(private price: number) {}
}

✅ Good Example:

class Price {
  constructor(private value: number) {
    if (value <= 0) throw new Error('Price must be positive');
  }

  getAmount(): number {
    return this.value;
  }
}

class Order {
  constructor(private price: Price) {}
}

By wrapping primitives, we ensure data integrity at the object level.

Rule: Use First-Class Collections

Instead of passing around raw arrays, encapsulate them in objects.

❌ Bad Example:

class Cart {
  constructor(public items: string[]) {}
}

✅ Good Example:

class CartItems {
  constructor(private items: string[]) {}

  addItem(item: string): void {
    this.items.push(item);
  }

  getItems(): string[] {
    return this.items;
  }
}

class Cart {
  constructor(private items: CartItems) {}
}

Encapsulating collections prevents direct manipulation and improves data encapsulation.

Rule: One Dot Per Line (Law of Demeter)

A class should only talk to direct dependencies, not deeply nested objects.

❌ Bad Example:

const city = user.getAddress().getCity();

✅ Good Example:

class Address {
  constructor(private city: string) {}
  getCity(): string {
    return this.city;
  }
}

class User {
  constructor(private address: Address) {}
  getCity(): string {
    return this.address.getCity();
  }
}

const city = user.getCity();

This reduces coupling and makes code easier to refactor.

Rule: Don’t Abbreviate
Code should be self-explanatory; avoid unnecessary abbreviations.

❌ Bad Example:

class Prsn {
  constructor(public nm: string) {}
}

✅ Good Example:

class Person {
  constructor(public name: string) {}
}

Rule: Keep Entities Small

Each class should have a single responsibility.

❌ Bad Example: (Mixing concerns in one class)

class User {
  constructor(private name: string, private email: string) {}

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

✅ Good Example: (Separate concerns into different classes)

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

class User {
  constructor(private name: string, private email: string) {}

  getEmail(): string {
    return this.email;
  }
}

This ensures that each class has a single responsibility.

Rule: No Classes with More than Two Instance Variables

Limit dependencies to keep classes small and focused.

❌ Bad Example:

class Order {
  constructor(
    private id: string,
    private customer: string,
    private items: string[],
    private status: string
  ) {}
}

✅ Good Example: (Use separate classes to manage complexity)

class OrderId {
  constructor(private value: string) {}
}

class OrderStatus {
  constructor(private status: string) {}
}

class Order {
  constructor(
    private id: OrderId,
    private customer: string,
    private items: string[],
    private status: OrderStatus
  ) {}
}

By breaking down complexity, we improve maintainability.

Rule: No Getters/Setters

Encapsulate logic within domain objects instead of exposing raw properties.

❌ Bad Example:

class Account {
  constructor(private balance: number) {}

  getBalance(): number {
    return this.balance;
  }
}

✅ Good Example:

class Account {
  constructor(private balance: number) {}

  withdraw(amount: number): void {
    if (amount > this.balance) throw new Error('Insufficient funds');
    this.balance -= amount;
  }
}

This enforces domain-driven behavior.

Conclusion

Object Calisthenics provides practical exercises to improve code quality, readability, and maintainability in OOP. By following these rules, you can:

→ Write cleaner and more maintainable object-oriented code.
→ Reduce complexity and coupling.
→ Improve code scalability for large applications.

Understanding the CAP Theorem: Consistency, Availability, and Partition Tolerance

Wallace Freitas — Fri, 07 Mar 2025 18:16:44 +0000

In the world of distributed systems, ensuring high performance and reliability is no easy task. The CAP theorem, formulated by Eric Brewer in 2000, serves as a guiding principle for designing and managing distributed databases. It states that a distributed system can guarantee only two out of three properties:

➡️ Consistency (C) – Every node sees the same data at the same time.

➡️ Availability (A) – Every request receives a response, even if some nodes fail.

➡️ Partition Tolerance (P) – The system continues to function despite network failures.

In this blog post, we’ll break down each component, explore real-world examples, and discuss how databases like MongoDB, Cassandra, and PostgreSQL make trade-offs based on CAP.

1. Breaking Down the CAP Theorem

Let’s dive deeper into the three properties of the CAP theorem.

Property	Explanation	Example
Consistency (C)	Every read receives the most recent write or an error.	SQL databases like PostgreSQL prioritize strong consistency.
Availability (A)	Every request gets a (possibly outdated) response.	Cassandra and DynamoDB prioritize availability over strict consistency.
Partition Tolerance (P)	The system works despite network failures.	Almost all distributed databases need partition tolerance.

A distributed database must choose between CA, CP, or AP, but never all three at the same time.

2. CAP Theorem Trade-offs: CA, CP, and AP Systems

Since perfect Consistency, Availability, and Partition Tolerance cannot coexist in a distributed system, let’s explore the three possible combinations.

CA (Consistency + Availability, No Partition Tolerance)

→ Guarantees data consistency and availability as long as the network is stable.

→ If a partition occurs, the system must go down to maintain consistency.

Example: Relational databases like MySQL and PostgreSQL (single-node setup)

Limitation: It does not handle network partitions well.

CP (Consistency + Partition Tolerance, No Availability)

→ Guarantees consistency even when network failures occur.

→ Some requests might be denied or delayed to maintain data accuracy.

Example: MongoDB (when configured for strong consistency), Zookeeper

Limitation: May sacrifice availability during network failures.

AP (Availability + Partition Tolerance, No Strong Consistency)

→ Ensures the system is always available, even if some data is stale.

→ Prioritizes availability over strict consistency.

Example: Cassandra, DynamoDB, and CouchDB

Limitation: Eventual consistency means clients may see outdated data.

3. CAP Theorem in Real-World Databases

Database	CAP Classification	Why?
PostgreSQL	CA	Strong consistency and high availability, but not designed for network partitions.
MongoDB (CP)	CP	Prioritizes consistency and partition tolerance with strong write concern.
Cassandra	AP	Always available and partition-tolerant but allows stale data (eventual consistency).
DynamoDB	AP	Designed for availability and resilience to network failures.

4. Choosing the Right Model for Your Application

Use Case	Recommended Database	Why?
Banking Systems (Strict consistency needed)	CP (MongoDB, Zookeeper)	Ensures accurate transactions.
Social Media Feeds (Fast availability over consistency)	AP (Cassandra, DynamoDB)	Users can tolerate slight delays in updates.
E-commerce Inventory (Balanced consistency & availability)	CA (PostgreSQL, MySQL in multi-node setup)	Ensures accurate stock counts without frequent partitions.

If network failures are rare, a CA system may work well. If high availability is crucial, an AP system might be better.

5. Conclusion

The CAP theorem forces us to prioritize what matters most in a distributed system.

✅ If data accuracy is critical, choose CP (e.g., banking transactions).

✅ If uptime is crucial, choose AP (e.g., social networks, caching).

✅ If you control network reliability, choose CA (e.g., enterprise applications).

By understanding CAP trade-offs, you can make informed decisions when designing distributed architectures.

Supercharge Your REST APIs with HATEOAS: The Key to Smarter, Self-Discoverable Endpoints

Wallace Freitas — Wed, 26 Feb 2025 12:15:40 +0000

Hypermedia as the Engine of Application State, or HATEOAS, is a key idea in contemporary API design that improves RESTful APIs by making them more discoverable and self-descriptive. Instead of depending on hardcoded endpoints, it enables clients to dynamically explore an API through hypermedia links.

In this article, we’ll explore:

✅ What HATEOAS is and why it matters.
✅ How it improves API usability.
✅ A practical implementation using Node.js and Express.

What is HATEOAS?

HATEOAS is a limitation of RESTful API architecture, in which hyperlinks included in answers allow a client to communicate with a server. The client follows links that are presented dynamically rather than knowing all potential API endpoints beforehand.

Example Without HATEOAS (Traditional API Response)

{
  "id": 1,
  "name": "John Doe",
  "email": "john@example.com"
}

The client must already know where to send requests to update or delete the user.

Example With HATEOAS (Hypermedia Links)

{
  "id": 1,
  "name": "John Doe",
  "email": "john@example.com",
  "_links": {
    "self": { "href": "/users/1" },
    "update": { "href": "/users/1", "method": "PUT" },
    "delete": { "href": "/users/1", "method": "DELETE" }
  }
}

Here, the response guides the client on how to interact with the resource.

Why Use HATEOAS?

✅ Benefits of HATEOAS	❌ Challenges of HATEOAS
Self-Descriptive APIs – Clients don’t need prior knowledge of all endpoints.	Increased Payload Size – Responses contain additional metadata.
Loose Coupling – Clients dynamically discover API capabilities via links.	More Complexity – Requires proper API design to generate dynamic links.
Improved Maintainability – API changes won’t break clients relying on hypermedia.

Implementing HATEOAS in a Node.js API

Let’s build a simple REST API with HATEOAS using Node.js and Express.

Step 1: Install Dependencies

npm init -y
npm install express

Step 2: Set Up Express Server

import express from "express";

const app = express();
const port = 3000;

app.use(express.json());

// Sample Users
const users = [
  { id: 1, name: "John Doe", email: "john@example.com" },
  { id: 2, name: "Jane Smith", email: "jane@example.com" }
];

// Helper function to generate HATEOAS links
const generateUserLinks = (userId: number) => ({
  self: { href: `/users/${userId}` },
  update: { href: `/users/${userId}`, method: "PUT" },
  delete: { href: `/users/${userId}`, method: "DELETE" }
});

// GET all users
app.get("/users", (req, res) => {
  const response = users.map(user => ({
    ...user,
    _links: generateUserLinks(user.id)
  }));
  res.json(response);
});

// GET a single user with HATEOAS links
app.get("/users/:id", (req, res) => {
  const user = users.find(u => u.id === parseInt(req.params.id));
  if (!user) return res.status(404).json({ error: "User not found" });

  res.json({ ...user, _links: generateUserLinks(user.id) });
});

app.listen(port, () => console.log(`Server running on http://localhost:${port}`));

Testing the API

Run the server:

node index.js

Retrieve Users:

GET /users

Response:

[
  {
    "id": 1,
    "name": "John Doe",
    "email": "john@example.com",
    "_links": {
      "self": { "href": "/users/1" },
      "update": { "href": "/users/1", "method": "PUT" },
      "delete": { "href": "/users/1", "method": "DELETE" }
    }
  }
]

The client can follow these links dynamically instead of hardcoding API paths.

When to Use HATEOAS?

Scenario	Should You Use HATEOAS?	Why?
Public APIs	✅ Yes	Provides flexibility for third-party clients
Microservices	✅ Yes	Enables service discovery and adaptability
Small APIs	❌ No	May add unnecessary complexity
Performance-Critical APIs	⚠️ Maybe	Adds extra response data, but can be optimized

Conclusion

HATEOAS makes APIs more flexible and self-explanatory, which enhances their usefulness. Clients can now follow hypermedia URLs instead of hardcoding API paths. In large APIs and microservices, it improves scalability, flexibility, and maintainability although adding some complexity.

Key Takeaways:

→ HATEOAS enables hypermedia-driven RESTful APIs.
→ Clients discover endpoints dynamically through embedded links.
→ Best suited for public APIs and microservices.
→ Adds flexibility, but comes with performance trade-offs.

By implementing HATEOAS, you’re one step closer to truly RESTful API design!

Understanding Domain Name System (DNS): Recursive & Iterative Queries with Root-Level Domains

Wallace Freitas — Wed, 12 Feb 2025 18:22:24 +0000

The foundation of the internet is the Domain Name System (DNS), which converts easily readable domain names (such as google.com) into IP addresses that computers may use to connect. In the absence of DNS, we would have to commit lengthy numerical addresses to memory rather than only the names of websites.

In this article, we’ll explore:

→ How DNS works
→ Recursive vs. Iterative DNS queries
→ The role of root-level domain name servers

How DNS Works

Your computer is unable to locate a URL like example.com when you type it into your browser. To obtain the relevant IP address, it must make a query to DNS servers. In order to resolve the domain, several DNS servers must speak with one another.

Key Components of DNS:

➡️ DNS Resolver – The first contact point that queries DNS servers.

➡️ Root DNS Server – The top of the hierarchy, directing queries to relevant Top-Level Domain (TLD) servers (e.g., .com, .org).

➡️ TLD DNS Server – Responsible for specific domain extensions (.com, .net, .org).

➡️ Authoritative DNS Server – Holds the actual IP address of the requested domain.

Recursive vs. Iterative DNS Queries

DNS queries can be recursive or iterative, depending on how they are processed.

Recursive Query

A recursive DNS query means the DNS resolver takes full responsibility for finding the answer. It queries multiple DNS servers on behalf of the client until it gets the correct IP address.

Example of Recursive Query Flow:

1️⃣ The user’s device asks the DNS Resolver (e.g., ISP’s DNS server) for example.com

2️⃣ The resolver contacts the Root DNS Server, which directs it to the TLD Server (.com).

3️⃣ The TLD Server points to the Authoritative DNS Server, which knows the actual IP of example.com.

4️⃣ The resolver returns the IP address to the client.

Recursive queries reduce client-side processing but put more load on the resolver.

Iterative Query

An iterative DNS query means the DNS resolver does not fetch the final answer but instead returns referrals to the client, which must query the next server itself.

Example of Iterative Query Flow:

1️⃣ The user’s device contacts the Root DNS Server.

2️⃣ The root server responds with a referral to the TLD DNS Server (.com).

3️⃣ The client queries the TLD Server, which responds with a referral to the Authoritative DNS Server.

4️⃣ The client asks the authoritative server, which finally provides the IP address.

Iterative queries reduce the resolver’s workload but require the client to perform more queries.

Root-Level Domain Name Servers

The Root DNS Servers are the highest level in the DNS hierarchy. They are responsible for directing DNS queries to the appropriate Top-Level Domain (TLD) servers.

Key Facts about Root DNS Servers:

→ There are 13 sets of root DNS servers globally, named A to M.
→ They are managed by organizations like ICANN and Verisign.
→ They do not store all domain IPs but instead redirect queries to TLD servers.

Example of Root DNS Query:

If a user requests example.com, the root DNS server will not return an IP address but instead refer the request to the .com TLD server.

Conclusion

By converting domain names into IP addresses, DNS plays a vital part in making the internet user-friendly. Knowing the difference between recursive and iterative queries aids in DNS performance optimization, and understanding the function of root-level DNS servers clarifies how the internet's addressing system maintains its organization and effectiveness.

Understanding how these systems function may speed up troubleshooting and increase reliability, whether you're increasing performance or troubleshooting DNS difficulties.

Adopting NestJS in Legacy Projects: Benefits and Challenges

Wallace Freitas — Mon, 10 Feb 2025 19:38:45 +0000

It might be difficult to update a legacy project, particularly if the current architecture is firmly rooted in antiquated frameworks or coding conventions. The progressive Node.js framework NestJS has become well-known due to its integrated dependency injection, TypeScript compatibility, and modular design. Does it work well for legacy apps, though?

This post will discuss the advantages of implementing NestJS in legacy projects, potential obstacles, and workable solutions for seamless integration.

🤨 Why Consider NestJS for a Legacy Project?

Legacy applications often suffer from technical debt, tight coupling, and difficult maintainability. Moving to NestJS can provide:

✓ Modularity & Scalability – Break down monolithic structures into manageable modules.

✓ TypeScript Support – Improve maintainability with static typing.

✓ Built-in Dependency Injection – Makes testing and managing dependencies easier.

✓ Microservices & GraphQL Support – Eases future migration to modern architectures.

✓ Familiarity for Angular Developers – Uses a similar design pattern.

But making the transition isn’t always straightforward. Let's dive into both the benefits and challenges of adopting NestJS in a legacy project.

Benefits of Adopting NestJS in Legacy Systems

1️⃣ Improved Code Maintainability

There is frequently little separation of concerns and spaghetti code in legacy projects. By using controllers, services, and modules to enforce an organized architecture, NestJS improves the readability and maintainability of the software.

Example: Refactoring a Controller

Legacy Express.js controller:

app.get('/users', async (req, res) => {
  const users = await db.query('SELECT * FROM users');
  res.json(users);
});

Refactored in NestJS:

@Controller('users')
export class UserController {
  constructor(private readonly userService: UserService) {}

  @Get()
  async getAllUsers() {
    return this.userService.getUsers();
  }
}

Separation of concerns – The controller handles only HTTP routing, while the service handles business logic.

2️⃣ Incremental Migration with Modular Architecture

NestJS supports gradual migration, allowing teams to migrate feature by feature instead of rewriting everything at once. You can wrap existing Express.js routes inside NestJS, reducing the risk of migration.

Example: Using Express Inside NestJS

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

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  const expressApp = express();

  expressApp.get('/legacy-route', (req, res) => {
    res.send('This is from the legacy system');
  });

  app.use('/api', expressApp);
  await app.listen(3000);
}
bootstrap();

Allows NestJS and the legacy app to coexist during migration.

3️⃣ Enhanced Testing and Dependency Injection

Legacy applications often lack unit testing due to tight coupling. NestJS encourages writing testable code using built-in dependency injection (DI).

Example: Injecting a Service for Testability

@Injectable()
export class UserService {
  constructor(@InjectRepository(User) private userRepository: Repository<User>) {}

  async getUsers() {
    return this.userRepository.find();
  }
}

Easy to mock dependencies during testing.

4️⃣ Built-in Support for Microservices and GraphQL

If you plan to migrate to microservices, NestJS has built-in support for:

🔷 Microservices (gRPC, Kafka, RabbitMQ)
🔷 GraphQL APIs
🔷 WebSockets for real-time applications

You can slowly introduce these features without breaking the existing monolith.

Example: Enabling Kafka in NestJS

import { Module } from '@nestjs/common';
import { ClientsModule, Transport } from '@nestjs/microservices';

@Module({
  imports: [
    ClientsModule.register([
      { name: 'KAFKA_SERVICE', transport: Transport.KAFKA, options: { client: { brokers: ['localhost:9092'] } } },
    ]),
  ],
})
export class AppModule {}

Prepares your system for future scalability.

Challenges of Migrating to NestJS

1️⃣ Learning Curve for Teams New to NestJS

If your team is unfamiliar with NestJS and TypeScript, expect some ramp-up time.

Solution:
Start with small features and offer NestJS training.

2️⃣ Integrating with Legacy Databases

Older databases might have inconsistent schemas or stored procedures.

Solution:
Use TypeORM or Prisma to map legacy structures carefully.

3️⃣ Refactoring Large Codebases

Breaking a monolithic app into NestJS modules can be overwhelming.

Solution:
Use strangler pattern – migrate feature by feature.

Migration Strategies for NestJS

→ Hybrid Approach (Express + NestJS) – Start by integrating NestJS modules into your existing Express app.

→ Module-by-Module Migration – Slowly move services into NestJS while keeping the legacy system operational.

→ Parallel Development – Build new features in NestJS while maintaining the legacy system.

Final Thoughts

Although it takes careful design, implementing NestJS in older programs can increase scalability, testability, and maintainability. You can implement contemporary best practices without interfering with your current application by doing feature-by-feature migrations.

Outbox Pattern with Kafka and NestJS: Ensuring Reliable Event-Driven Systems

Wallace Freitas — Mon, 03 Feb 2025 16:22:44 +0000

When integrating microservices in remote systems, data consistency and dependability are crucial. Making sure that database transactions and event publishing occur atomically is one of the most difficult tasks. An established remedy for this issue is the Outbox Pattern.

In this post, we'll examine the Outbox Pattern using Kafka and NestJS and show you how to use it successfully in a practical setting.

What is the Outbox Pattern?

The Outbox Pattern is a design pattern that ensures reliable event publishing by storing events in a database table (Outbox) before processing them asynchronously. This prevents issues where a service commits a database transaction but fails to publish an event, leading to inconsistent state across systems.

How It Works

1️⃣ A service writes a domain event to an Outbox Table within the same database transaction as the business data.

2️⃣ A separate process (poller or message relay) reads the Outbox Table and publishes events to Kafka.

3️⃣ Once an event is successfully sent, it is marked as processed or deleted.

Use Case: Order Processing with Outbox Pattern in NestJS

Imagine an e-commerce application where an Order Service needs to reliably publish events to Kafka when a new order is created.

Step 1: Set Up the NestJS Application

First, create a NestJS project and install necessary dependencies:

nest new outbox-kafka-demo
cd outbox-kafka-demo
npm install @nestjs/microservices kafkajs @nestjs/typeorm typeorm pg

Step 2: Define the Order and Outbox Entities

Create an Order entity and an Outbox entity using TypeORM.

order.entity.ts

import { Entity, PrimaryGeneratedColumn, Column, CreateDateColumn } from 'typeorm';

@Entity()
export class Order {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  customerId: number;

  @Column()
  status: string;

  @CreateDateColumn()
  createdAt: Date;
}

outbox.entity.ts

import { Entity, PrimaryGeneratedColumn, Column, CreateDateColumn } from 'typeorm';

@Entity()
export class OutboxEvent {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  eventType: string;

  @Column({ type: 'json' })
  payload: any;

  @Column({ default: false })
  processed: boolean;

  @CreateDateColumn()
  createdAt: Date;
}

Step 3: Create an Order Service to Write to the Outbox Table

Instead of publishing to Kafka directly, orders are saved to the database along with an outbox event in the same transaction.

order.service.ts

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { Order } from './order.entity';
import { OutboxEvent } from './outbox.entity';

@Injectable()
export class OrderService {
  constructor(
    @InjectRepository(Order) private readonly orderRepo: Repository<Order>,
    @InjectRepository(OutboxEvent) private readonly outboxRepo: Repository<OutboxEvent>,
  ) {}

  async createOrder(customerId: number): Promise<Order> {
    const order = this.orderRepo.create({ customerId, status: 'PENDING' });

    const outboxEvent = this.outboxRepo.create({
      eventType: 'OrderCreated',
      payload: { orderId: order.id, customerId },
    });

    await this.orderRepo.save(order);
    await this.outboxRepo.save(outboxEvent);

    return order;
  }
}

Step 4: Implement a Poller to Process Outbox Events

A separate background job will read unprocessed events and publish them to Kafka.

outbox.processor.ts

import { Injectable, OnModuleInit } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { OutboxEvent } from './outbox.entity';
import { KafkaProducerService } from './kafka.producer.service';

@Injectable()
export class OutboxProcessor implements OnModuleInit {
  constructor(
    @InjectRepository(OutboxEvent) private readonly outboxRepo: Repository<OutboxEvent>,
    private readonly kafkaProducer: KafkaProducerService,
  ) {}

  async processEvents() {
    const events = await this.outboxRepo.find({ where: { processed: false } });

    for (const event of events) {
      await this.kafkaProducer.sendMessage('order-events', event.payload);
      event.processed = true;
      await this.outboxRepo.save(event);
    }
  }

  onModuleInit() {
    setInterval(() => this.processEvents(), 5000); // Run every 5 seconds
  }
}

Step 5: Kafka Producer to Publish Events

The Kafka Producer will send the message to the Kafka topic.

kafka.producer.service.ts

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

@Injectable()
export class KafkaProducerService {
  private kafka = new Kafka({ brokers: ['localhost:9092'] });
  private producer = this.kafka.producer();

  async sendMessage(topic: string, message: any) {
    await this.producer.connect();
    await this.producer.send({
      topic,
      messages: [{ value: JSON.stringify(message) }],
    });
    await this.producer.disconnect();
  }
}

Step 6: Kafka Consumer to Process Events

A Kafka Consumer will listen to the order-events topic and process messages.

kafka.consumer.service.ts

import { Injectable, OnModuleInit } from '@nestjs/common';
import { Kafka } from 'kafkajs';

@Injectable()
export class KafkaConsumerService implements OnModuleInit {
  private kafka = new Kafka({ brokers: ['localhost:9092'] });
  private consumer = this.kafka.consumer({ groupId: 'order-group' });

  async onModuleInit() {
    await this.consumer.connect();
    await this.consumer.subscribe({ topic: 'order-events', fromBeginning: true });

    await this.consumer.run({
      eachMessage: async ({ message }) => {
        console.log('Received message:', message.value.toString());
      },
    });
  }
}

🤨 How This Ensures Reliability

✅ Atomicity: The order and outbox event are saved in one transaction.

✅ Retry Mechanism: If Kafka is down, the event stays in the database until it's processed.

✅ Guaranteed Delivery: Events will not be lost if the service crashes.

In NestJS applications that use Kafka, the Outbox Pattern is a potent way to guarantee dependable event-driven communication. By separating the database transaction from the message publishing process, we prevent inconsistencies and data loss.

To increase reliability when developing scalable microservices, think about using the Outbox Pattern.

Micro x Macro Software Architectures

Wallace Freitas — Tue, 28 Jan 2025 19:25:09 +0000

In the evolving world of software development, choosing the right architecture is key to building robust, scalable, and maintainable systems. Two critical perspectives often come into play: Micro Architecture and Macro Architecture. While these approaches focus on different aspects of system design, leveraging both is essential for creating resilient and adaptable software.

🤨 What is Micro Architecture?

Micro Architecture focuses on the internal structure and design of individual components or services. It dictates how a specific module or feature is implemented, emphasizing low-level details such as:

➡️ Coding practices and patterns (e.g., Factory, Singleton).
➡️ Internal APIs and interactions within a service.
➡️ Data structures, algorithms, and object relationships.

Examples

🤖 Password Hashing in an Authentication Module

Micro Architecture ensures that internal logic, such as password hashing, is efficient and secure.

const bcrypt = require('bcrypt');

// Micro: Internal implementation of password hashing
async function hashPassword(password) {
    const saltRounds = 10;
    return await bcrypt.hash(password, saltRounds);
}

async function verifyPassword(password, hashedPassword) {
    return await bcrypt.compare(password, hashedPassword);
}

module.exports = { hashPassword, verifyPassword };

🤖 Singleton Pattern for Database Connections

A Singleton ensures a single shared connection to a database.

const { MongoClient } = require('mongodb');

let instance = null;

async function getDatabase() {
    if (!instance) {
        const client = new MongoClient('mongodb://localhost:27017');
        instance = client.db('exampleDb');
    }
    return instance;
}

module.exports = { getDatabase };

🤖 Reusable Utility Functions

Encapsulate shared logic within services.

function validateEmail(email) {
    const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    return emailRegex.test(email);
}

module.exports = { validateEmail };

🤨 What is Macro Architecture?

Macro Architecture, on the other hand, is about the big-picture structure of the system. It defines how different components or services interact and outlines high-level design principles such as:

➡️ System topology (e.g., monolith vs. microservices).
➡️ Communication protocols (e.g., REST, GraphQL, message queues).
➡️ Deployment strategies (e.g., container orchestration, serverless).

Examples

In the context of the same user authentication service, Macro Architecture addresses:

How the service communicates with other services (e.g., user profiles, payment systems).

Whether it is deployed as a standalone microservice or part of a monolith.

The use of an event bus for broadcasting authentication events.
Why You Need Both

1️⃣ Balance Between Granularity and Scalability

Micro Architecture ensures that each module is efficient and adheres to best practices.
Macro Architecture ensures that the entire system scales seamlessly, even as new modules are added.

2️⃣ Improved Collaboration

Macro Architecture provides the overall structure, helping teams understand how their work fits into the bigger picture.
Micro Architecture empowers individual teams to focus on fine-tuned, domain-specific solutions.

3️⃣ Adaptability

With strong Macro Architecture, you can easily replace or upgrade components.
With robust Micro Architecture, components are more maintainable and less prone to bugs.

4️⃣ Resilience to Failure

Macro Architecture enforces boundaries between services, ensuring that one service's failure doesn’t cascade.
Micro Architecture ensures fault tolerance and retry mechanisms within services.

Combining Micro and Macro Architectures

Here’s how to leverage both:

Aspect	Micro Architecture	Macro Architecture
Focus	Internal implementation details	System-wide communication and structure
Scope	Individual services or modules	Entire system or ecosystem
Key Design Choices	Design patterns, algorithms, APIs	Topology, protocols, deployment strategies
Example Decision	How to hash passwords	How authentication service communicates
Goal	Code quality, maintainability, efficiency	Scalability, reliability, system integrity
Responsibility	Ensuring the effectiveness of a single unit	Ensuring cohesion among all system components
Change Impact	Affects only the module	Affects the entire system
Flexibility	Enables rapid changes within a service	Facilitates long-term architectural goals

Macro and microarchitectures complement approaches rather than rival approaches. Macro Architecture makes sure the intricacies blend together into the overall system, whereas Micro Architecture focuses on the finer points. When combined, they provide durable, scalable, and maintainable software that can change to meet your company's demands.

The Pipeline Pattern: Streamlining Data Processing in Software Architecture

Wallace Freitas — Fri, 10 Jan 2025 17:14:01 +0000

Efficient data processing and transformation are critical components of contemporary software systems. An effective architectural design for handling a number of data transformations in a tidy, modular, and expandable manner is the Pipeline Pattern. We will examine the Pipeline Pattern, its advantages, and its real-world applications in this blog article, with a focus on Node.js and TypeScript.

⁉️ What is the Pipeline Pattern?

The Pipeline Pattern organizes data processing into a sequence of discrete stages. Each stage transforms the data and passes it to the next, creating a streamlined flow of operations. This approach is particularly useful for tasks like:

→ Data validation and enrichment.
→ Complex transformations.
→ Event stream processing.

😍 Benefits of the Pipeline Pattern

Modularity: Each stage in the pipeline is encapsulated, making it easier to test and maintain.

Reusability: Pipeline stages can be reused across different pipelines or applications.

Scalability: Processing can be distributed across systems or cores for improved performance.

Extensibility: New stages can be added without disrupting the existing pipeline structure.

👨‍🔬 Implementing the Pipeline Pattern in Node.js with TypeScript

Let’s create a simple example that processes an array of user data through a pipeline.

Use Case: Normalize user data by converting names to uppercase, validating email formats, and enriching the data with a timestamp.

interface User {
  name: string;
  email: string;
  timestamp?: string;
}

type PipelineStage = (input: User) => User;

// Stage 1: Convert names to uppercase
const toUpperCaseStage: PipelineStage = (user) => {
  return { ...user, name: user.name.toUpperCase() };
};

// Stage 2: Validate email format
const validateEmailStage: PipelineStage = (user) => {
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!emailRegex.test(user.email)) {
    throw new Error(`Invalid email format: ${user.email}`);
  }
  return user;
};

// Stage 3: Enrich data with timestamp
const enrichDataStage: PipelineStage = (user) => {
  return { ...user, timestamp: new Date().toISOString() };
};

// Pipeline runner
const runPipeline = (user: User, stages: PipelineStage[]): User => {
  return stages.reduce((currentData, stage) => stage(currentData), user);
};

// Example usage
const userData: User = { name: "John Doe", email: "john.doe@example.com" };
const stages: PipelineStage[] = [toUpperCaseStage, validateEmailStage, enrichDataStage];

try {
  const processedUser = runPipeline(userData, stages);
  console.log(processedUser);
} catch (error) {
  console.error(error.message);
}

Use Case: Asynchronous Pipelines

In many real-world scenarios, each stage might involve asynchronous operations, such as API calls or database queries. The Pipeline Pattern supports asynchronous stages with slight modifications.

// Asynchronous stage type
type AsyncPipelineStage = (input: User) => Promise<User>;

// Example: Asynchronous data enrichment
const asyncEnrichDataStage: AsyncPipelineStage = async (user) => {
  // Simulate an API call
  await new Promise((resolve) => setTimeout(resolve, 100));
  return { ...user, enriched: true };
};

// Asynchronous pipeline runner
const runAsyncPipeline = async (user: User, stages: AsyncPipelineStage[]): Promise<User> => {
  for (const stage of stages) {
    user = await stage(user);
  }
  return user;
};

// Example usage
(async () => {
  const asyncStages: AsyncPipelineStage[] = [
    asyncEnrichDataStage,
    async (user) => ({ ...user, processed: true }),
  ];

  const result = await runAsyncPipeline(userData, asyncStages);
  console.log(result);
})();

📝 When to Use the Pipeline Pattern

The Pipeline Pattern is ideal for:

1️⃣ Data Processing Pipelines: ETL (Extract, Transform, Load) operations.

2️⃣ Middleware Chains: HTTP request/response processing.

3️⃣ Stream Processing: Real-time event or message handling.

4️⃣ Image or Video Processing: Applying multiple transformations in sequence.

Conclusion

One of the most useful and effective tools in a developer's toolbox is the Pipeline Pattern. It gives complicated workflows clarity, maintainability, and extension. Using this pattern can greatly improve the design of your application, regardless of whether you're dealing with synchronous or asynchronous tasks.

Query Objects Instead of Repositories: A Modern Approach to Data Access

Wallace Freitas — Tue, 31 Dec 2024 14:11:50 +0000

As software systems grow in complexity, organizing and accessing data effectively becomes paramount. Traditional Repository patterns, which abstract data access logic, are often sufficient but can become cumbersome when dealing with complex query logic. Enter the Query Object pattern, a design approach that separates query logic from repositories to enhance flexibility, readability, and maintainability.

In this blog post, we'll explore the concept of Query Objects, contrast them with repositories, and implement examples using Node.js and TypeScript.

What Are Query Objects?

Query Objects encapsulate database query logic into dedicated classes or functions. Instead of cluttering repositories with various methods to handle different queries, each Query Object is responsible for one specific query. This separation simplifies code, improves testability, and promotes single-responsibility principles.

Key Features of Query Objects

1️⃣ Single Responsibility:
Focus on a single query or data-fetching operation.

2️⃣ Reusability:
Queries can be reused across different services or modules.

3️⃣ Testability:
Easier to isolate and test queries independently.

4️⃣ Readability:
Keeps repositories clean and query logic focused.

Why Replace Repositories with Query Objects?

Repositories typically combine multiple responsibilities, including:

✓ CRUD operations.
✓ Complex filtering and sorting logic.
✓ Data transformation.

This can lead to bloated classes that are harder to maintain and extend. Query Objects provide a cleaner alternative by decoupling query logic and delegating it to specialized units.

Implementing Query Objects in Node.js with TypeScript

Scenario

We are building a blogging platform and need to implement queries for fetching published articles and articles by author.

Traditional Repository Example

// articleRepository.ts
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

export class ArticleRepository {
  async findPublished(): Promise<Article[]> {
    return prisma.article.findMany({
      where: { published: true },
    });
  }

  async findByAuthor(authorId: string): Promise<Article[]> {
    return prisma.article.findMany({
      where: { authorId },
    });
  }
}

While this works, the repository can quickly become bloated with additional methods for other queries.

Refactored with Query Objects

Query Object for Published Articles

// queries/findPublishedArticles.ts
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

export class FindPublishedArticles {
  async execute(): Promise<Article[]> {
    return prisma.article.findMany({
      where: { published: true },
    });
  }
}

Query Object for Articles by Author

// queries/findArticlesByAuthor.ts
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

export class FindArticlesByAuthor {
  constructor(private authorId: string) {}

  async execute(): Promise<Article[]> {
    return prisma.article.findMany({
      where: { authorId: this.authorId },
    });
  }
}

Using Query Objects

import { FindPublishedArticles } from './queries/findPublishedArticles';
import { FindArticlesByAuthor } from './queries/findArticlesByAuthor';

async function main() {
  const findPublishedArticles = new FindPublishedArticles();
  const publishedArticles = await findPublishedArticles.execute();
  console.log('Published Articles:', publishedArticles);

  const findArticlesByAuthor = new FindArticlesByAuthor('author-id-123');
  const authorArticles = await findArticlesByAuthor.execute();
  console.log('Author Articles:', authorArticles);
}

main();

Benefits of Query Objects

Benefit	Description
Single Responsibility	Focuses solely on query logic, ensuring each class has a clear and specific purpose.
Code Reusability	Query Objects are modular and can be easily reused across different parts of the application.
Scalability	Keeps the codebase manageable by preventing bloated repositories as queries increase.
Testing	Simplifies unit testing by isolating query logic into independent, testable units.
Maintainability	Improves readability and organization by separating concerns in data access logic.

When to Use Query Objects

Query Objects are ideal when:

Your application has complex or evolving query requirements.
You need to separate concerns for better maintainability.
You want highly testable query logic.

For simple CRUD operations, repositories may still be sufficient. However, as query complexity grows, adopting Query Objects can significantly improve your codebase.

Conclusion

The Query Object pattern offers a modern, modular approach to managing complex data-fetching logic. By encapsulating each query into its own dedicated class, you can achieve cleaner, more maintainable code while adhering to the single-responsibility principle.

Start using Query Objects in your Node.js and TypeScript projects to simplify query logic and unlock better scalability for your applications.

Real-Time Data Indexing: Powering Instant Insights and Scalable Querying

Wallace Freitas — Fri, 27 Dec 2024 19:51:32 +0000

The explosion of data in modern systems has created new challenges for developers and organizations alike. Handling massive volumes of information while ensuring fast and flexible access requires innovative approaches. Enter Real-Time Data Indexing, a strategy that empowers systems to:

Index Everything: Seamlessly store and organize data, regardless of structure or source.

Query Anything: Provide users with the ability to retrieve insights using highly flexible queries.

In Real-Time: Deliver instant results for live analytics, search, or decision-making.

This article delves into real-time data indexing, its core principles, and practical implementation strategies, with a focus on building systems that can scale dynamically.

🤨 What is Real-Time Data Indexing?

Real-time data indexing refers to the process of:

Ingesting Data: Capturing structured, semi-structured, or unstructured data from various sources.

Indexing Data: Organizing it in a way that supports rapid retrieval.

Querying in Real-Time: Allowing users to perform searches and analyses instantly.

This approach is essential in scenarios like live search engines, recommendation systems, financial analytics, and IoT applications, where latency is critical.

🔑 Key Features

Low Latency: Ensures updates to the index are available for querying within milliseconds.

High Scalability: Supports increasing data volumes and user queries efficiently.

Schema Flexibility: Accommodates diverse data types and sources.

Query Versatility: It allows complex queries combining full-text search, filtering, and aggregations.

Technologies Supporting Real-Time Data Indexing

Several tools and frameworks make real-time indexing possible:

Elasticsearch: Powerful search and analytics engine for unstructured and semi-structured data.

Apache Kafka: Enables real-time data streaming for continuous updates to indexes.

Redis: Provides in-memory indexing for ultra-low-latency queries.

ClickHouse: A columnar database optimized for real-time analytics.

🧱 Implementation Steps

1️⃣ Data Ingestion
Set up pipelines to collect data from sources like databases, APIs, or IoT devices. Tools like Kafka or Logstash can handle real-time ingestion efficiently.

2️⃣ Indexing Data
Choose an indexing solution (e.g., Elasticsearch, Redis) and configure schemas to accommodate your data types. For example:

Elasticsearch Index Configuration (JSON):

PUT /my_index
{
  "mappings": {
    "properties": {
      "timestamp": { "type": "date" },
      "message": { "type": "text" },
      "status": { "type": "keyword" }
    }
  }
}

3️⃣ Handling Queries
Define and execute queries to extract insights. Queries can include full-text search, filters, and aggregations.

Elasticsearch Query Example:

GET /my_index/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "message": "error" } },
        { "term": { "status": "critical" } }
      ]
    }
  }
}

4️⃣ Ensuring Real-Time Updates
Configure data pipelines to stream updates directly to the indexing engine. For instance, use Kafka to feed new records into Elasticsearch in real time.

Use Cases

🛒 E-Commerce Search
Index product catalogs for instant search and filtering by attributes like price, category, and reviews.

📈 Log Analytics
Monitor application logs in real time to detect and act on errors or anomalies.

💳 Fraud Detection
Analyze transaction data to flag suspicious activities as they occur.

🤖 IoT Monitoring
Process sensor data for real-time alerts and dashboard visualizations.

Challenge	Solution
High Ingestion Rates	Use Kafka or similar tools for scalable data ingestion.
Query Latency	Optimize indexes and leverage in-memory databases like Redis.
Schema Evolution	Adopt schema-less or flexible schema tools like Elasticsearch or MongoDB.
Scaling Infrastructure	Use horizontal scaling and cloud-native services like AWS OpenSearch.

Conclusion

Real-time data indexing transforms how we interact with data by enabling immediate insights and decision-making. By indexing everything and offering real-time, flexible querying capabilities, businesses can unlock the full potential of their data. Start building real-time indexing pipelines today, and empower your applications with the speed and flexibility they need to thrive in the data-driven world.