Forem: Tomás Alegre Sepúlveda

🔬 NestJS vs Go: Performance Benchmark (Do you really need to migrate?)

Tomás Alegre Sepúlveda — Tue, 10 Mar 2026 02:00:34 +0000

Hello everyone. I recently conducted an exhaustive benchmark to answer a classic question in backend teams: does it make sense to migrate to Go, or is NestJS enough?

There is no magic answer, but data helps decide. Here is a summary of the most important findings.

🏗️ The Scenario

I compared two typical architectures running in Docker on the same machine (M4 Pro):

NestJS (Node 22) + Prisma v6 (Productivity approach)
Go (1.24) + GORM (Performance approach)

Both connected to PostgreSQL 15 and subjected to stress tests (gRPC and HTTP) simulating a real environment.

🧪 Methodology: What did we measure?

To truly understand the differences, I divided the tests into two key scenarios:

Small Data (1x1 Insert):
Simulates typical transactional traffic of a REST/gRPC API. We receive an object, validate it, and save it. Here we measure the framework's base latency.
Large Data (Batch Insert of 1000 elements):
Simulates bulk load processes, ETLs, or event ingestion. We send arrays of 1000 objects that must be deserialized, validated, and saved in a single transaction. This is where CPU and Garbage Collector suffer the most.

📊 The Results

1. Small Data: The Surprise

In low load or unit insert scenarios, the difference was minimal. Go obtained a latency improvement of just ~10% over NestJS.

Conclusion: For standard CRUD operations, NestJS is incredibly efficient, and the performance difference rarely justifies losing TypeScript's productivity.

2. Large Data: The Breaking Point

The story changes drastically when processing massive batches (arrays of 1000 elements) under high concurrency.

Scenario: 100 RPS constant (Bulk Inserts)

Service	Real Throughput	P95 Latency	Success Rate
Go gRPC	85 RPS	71.88 ms	100%
NestJS gRPC	78 RPS	98.44 ms	~85%

What happened here?

Serialization: Node.js (V8) has a higher cost when serializing/deserializing large volumes of JSON compared to Go Structs and Protobuf.
Connection Pool: Under extreme pressure, the Prisma connection pool started to saturate (P2024 errors), causing NestJS to lose ~15% of requests.
Stability: Go maintained 100% success and more predictable latencies, thanks to its goroutine management and a more efficient GC for this type of load.

⚖️ Conclusion: When to use which?

Based on the data, here is my pragmatic recommendation:

✅ Stay with NestJS if:

You are building an MVP or validating a product.
Your team already knows TypeScript and you value development speed.
The load is moderate (< 300 RPS) and standard CRUD operations (Small Data).
BFF (Backend for Frontend): If you only need to orchestrate calls to a few services and the serialization load is low.

🚀 Migrate to Go if:

Complex BFF: If your BFF needs to call many microservices, add heavy logic, serialize large volumes of data, and perform massive fan-out, Go will handle concurrency much better.
Your system constantly performs massive Bulk Operations / ETL (Large Data).
You need to handle thousands of concurrent connections (e.g., Gateways, massive Websockets).
You have very strict latency SLAs where Node's Garbage Collector spikes are unacceptable.
Infrastructure is expensive and you need to squeeze every CPU cycle.

📖 Read the full analysis

This post is a summary. The detailed analysis (with all tables, charts, hardware configuration, and error analysis) is public and free.

👉 Read the full article on Buy Me a Coffee

💻 View code on GitHub

💌 Special Acknowledgments

To a girl who, without knowing it, pushed me to keep creating and programming in my free time. To the one who was once my spark: for "YLP", with gratitude... and with scars that also teach.

If you find this analysis useful, any feedback is welcome!

🔬 NestJS vs Go: Benchmark de Rendimiento (¿Realmente necesitas migrar?)

Tomás Alegre Sepúlveda — Mon, 09 Mar 2026 00:17:36 +0000

🇺🇸 Read this post in English

Hola a todos. Recientemente realicé un benchmark exhaustivo para responder una pregunta clásica en equipos de backend: ¿tiene sentido migrar a Go, o alcanza con NestJS?

No hay respuesta mágica, pero los datos ayudan a decidir. Aquí les dejo un resumen de los hallazgos más importantes.

🏗️ El Escenario

Comparé dos arquitecturas típicas corriendo en Docker sobre la misma máquina (M4 Pro):

NestJS (Node 22) + Prisma v6 (Enfoque productividad)
Go (1.24) + GORM (Enfoque rendimiento)

Ambos conectados a PostgreSQL 15 y sometidos a pruebas de estrés (gRPC y HTTP) simulando un entorno real.

🧪 Metodología: ¿Qué medimos?

Para entender realmente las diferencias, dividí las pruebas en dos escenarios clave:

Small Data (1x1 Insert):
Simula el tráfico transaccional típico de una API REST/gRPC. Recibimos un objeto, lo validamos y lo guardamos. Aquí medimos la latencia base del framework.
Large Data (Batch Insert de 1000 elementos):
Simula procesos de carga masiva, ETLs o ingestión de eventos. Enviamos arrays de 1000 objetos que deben ser deserializados, validados y guardados en una sola transacción. Aquí es donde la CPU y el Garbage Collector sufren más.

📊 Los Resultados

1. Small Data: La sorpresa

En escenarios de baja carga o inserciones unitarias, la diferencia fue mínima. Go obtuvo una mejora de latencia de apenas un ~10% sobre NestJS.

Conclusión: Para operaciones CRUD estándar, NestJS es increíblemente eficiente y la diferencia de rendimiento rara vez justifica perder la productividad de TypeScript.

2. Large Data: El punto de quiebre

La historia cambia drásticamente cuando procesamos lotes masivos (arrays de 1000 elementos) bajo alta concurrencia.

Escenario: 100 RPS constantes (Bulk Inserts)

Servicio	Throughput Real	P95 Latency	Success Rate
Go gRPC	85 RPS	71.88 ms	100%
NestJS gRPC	78 RPS	98.44 ms	~85%

¿Qué pasó aquí?

Serialización: Node.js (V8) tiene un costo mayor al serializar/deserializar grandes volúmenes de JSON comparado con los Structs de Go y Protobuf.
Connection Pool: Bajo presión extrema, el pool de conexiones de Prisma comenzó a saturarse (errores P2024), provocando que NestJS perdiera el ~15% de los requests.
Estabilidad: Go mantuvo el 100% de éxito y latencias más predecibles, gracias a su manejo de goroutines y un GC más eficiente para este tipo de carga.

⚖️ Conclusión: ¿Cuándo usar cuál?

Basado en los datos, aquí está mi recomendación pragmática:

✅ Quédate con NestJS si:

Estás construyendo un MVP o validando producto.
Tu equipo ya conoce TypeScript y valoras la velocidad de desarrollo.
La carga es moderada (< 300 RPS) y operaciones CRUD estándar (Small Data).
BFF (Backend for Frontend): Si solo necesitas orquestar llamadas a pocos servicios y la carga de serialización es baja.

🚀 Migra a Go si:

BFF Complejo: Si tu BFF necesita llamar a muchos microservicios, agregar lógica pesada, serializar grandes volúmenes de datos y hacer fan-out masivo, Go manejará la concurrencia mucho mejor.
Tu sistema realiza Bulk Operations / ETL masivos constantemente (Large Data).
Necesitas manejar miles de conexiones concurrentes (ej. Gateways, Websockets masivos).
Tienes SLAs de latencia muy estrictos donde los picos del Garbage Collector de Node son inaceptables.

📖 Lee el análisis completo

Este post es un resumen. El análisis detallado (con todas las tablas, gráficos, configuración de hardware y análisis de errores) es público y gratuito.

👉 Leer el artículo completo en Buy Me a Coffee

💻 Ver el código en GitHub

💌 Agradecimientos Especiales

A una chica que, sin saberlo, me empujó a seguir creando y programando en mi tiempo libre. A quien alguna vez fue mi chispa: para “YLP”, con gratitud… y con cicatrices que también enseñan.

Si te sirve este tipo de análisis, ¡cualquier feedback es bienvenido!

🐳 Minecraft + Docker: My personal config to stop suffering with Java

Tomás Alegre Sepúlveda — Thu, 05 Feb 2026 04:19:41 +0000

🇪🇸 Lee este post en Español

I'm no Java guru, and I'll be honest: managing Minecraft servers has always felt like a weird puzzle to me. Even though Minecraft might look like a "random" game about placing blocks, the technical management behind a server (threads, memory, garbage collection) is a fascinating optimization challenge.

Back in the day, I tried creating plugins (with... "interesting" results), but I learned the hard way that the real battle is almost always the configuration.

Has this happened to you? You want to play Survival with friends, you search for "best paper 1.21 config", and you end up with 20 open tabs and three wikis that contradict each other.

The Initiative: Enough Chaos

Tired of copying and pasting the same configuration lines over and over again, I decided to build Paper Config Optimized.

I didn't want to make "just another guide". I wanted a place to truly centralize the community's best practices into ready-to-use files. In fact, I've become such a fan of this "infrastructure as code" approach that I recently made my first contribution to the official Docker image repository we use (PR #3076 in itzg/docker-minecraft-server) and plan to keep contributing to improve the ecosystem.

"The Recipe" (Configuration)

Here is the configuration I always use. It's basically my "copy, paste, and forget" template.

The important thing here is that we are telling Docker two key things:

"Use Aikar's Flags": So Java doesn't get picky with memory.
"Download configs from the repo": So the game runs smoothly without having to touch anything.

services:
  mc:
    image: itzg/minecraft-server
    container_name: paper-lite
    restart: unless-stopped
    ports:
      - "25565:25565"

    # Interactive console (never hurts to see what's happening)
    stdin_open: true
    tty: true

    environment:
      # Mojang bureaucracy and software choice (Paper flies)
      EULA: "TRUE"
      TYPE: "PAPER"

      # Always the latest. Living on the edge.
      VERSION: "LATEST"

      # We activate Aikar's flags.
      # Trust me, you don't want to manage the Garbage Collector manually.
      USE_AIKAR_FLAGS: "true"

      # Timezone (change to yours so logs make sense)
      TZ: "America/Santiago"

      # ✨ THE MAGIC:
      # Automatically injects optimized configs from the repo at startup.
      PAPER_CONFIG_REPO: "https://raw.githubusercontent.com/Alpha018/paper-config-optimized/main"

    volumes:
      - ./minecraft-data:/data

How to run this?

It's as simple as putting that into a docker-compose.yml file, opening a terminal in the folder, and throwing in a:

docker compose up -d

⚖️ Balance: Pros and Cons

As with everything in engineering, there are no silver bullets. This configuration is my favorite, but we have to be transparent:

✅ The Good (Pros)

Speed: Go from "zero" to "optimized server" in 2 minutes.
Maintenance: By using PAPER_CONFIG_REPO, if performance improvements come out tomorrow, you just have to restart the container to apply them.
Stability: Using Aikar's Flags eliminates 90% of lag spikes caused by Java.

❌ The Bad (Cons)

Black Box: If you like manually adjusting every millimeter of view-distance, you might feel like you're losing some control (although you can always overwrite the files).
Dependency: You depend on my repository (or your own fork) being online to download the configs at startup.

🚀 For Advanced Users

This configuration is ideal for what I call "Lite Technical Survival". But if you are planning to set up a massive public community (50+ players) or want to understand why 12GB of RAM is my magic number for large servers, I wrote a much deeper technical guide.

☕ Check out the Advanced Technical Guide on Buy Me a Coffee

💌 Special Acknowledgments

To a girl who, without knowing it, pushed me to keep creating and coding in my free time. To the one who was once my spark: for "YLP", with gratitude... and with scars that also teach.

🐳 Minecraft + Docker: Mi configuración personal para no sufrir con Java

Tomás Alegre Sepúlveda — Thu, 05 Feb 2026 04:18:11 +0000

🇺🇸 Read this post in English

No soy ningún gurú de Java, y seré honesto: gestionar servidores de Minecraft siempre me pareció un rompecabezas extraño. A pesar de que Minecraft pueda parecer un juego "random" de poner cubitos, la gestión técnica detrás de un servidor (hilos, memoria, recolección de basura) es un reto de optimización fascinante.

En su momento intenté crear plugins (con resultados... "interesantes"), pero aprendí a la mala que la verdadera batalla casi siempre es la configuración.

¿Te ha pasado? Quieres jugar un Survival con amigos, buscas "mejor configuración paper 1.21" y terminas con 20 pestañas abiertas y tres wikis que se contradicen.

La Iniciativa: Basta de Caos

Cansado de copiar y pegar las mismas líneas de configuración una y otra vez, se me ocurrió armar Paper Config Optimized.

No quería hacer "otra guía más". Quería un lugar donde centralizar de verdad las mejores prácticas de la comunidad en archivos listos para usar. De hecho, me he vuelto tan fan de esta "infraestructura como código" que hace poco hice mi primera contribución al repositorio oficial de la imagen de Docker que usamos (PR #3076 en itzg/docker-minecraft-server) y planeo seguir aportando para mejorar el ecosistema.

"La Receta" (Configuración)

Te dejo por aquí la configuración que uso siempre. Es básicamente mi plantilla de "copiar, pegar y olvidarse".

Lo importante aquí es que le estamos diciendo a Docker dos cosas clave:

"Usa Aikar's Flags": Para que Java no se ponga caprichoso con la memoria.
"Descargar las configs del repositorio": Para que el juego corra fluido sin tener que tocar nada.

services:
  mc:
    image: itzg/minecraft-server
    container_name: paper-lite
    restart: unless-stopped
    ports:
      - "25565:25565"

    # Consola interactiva (nunca está de más para ver qué pasa)
    stdin_open: true
    tty: true

    environment:
      # Papeleo burocrático de Mojang y elección del software (Paper vuela)
      EULA: "TRUE"
      TYPE: "PAPER"

      # Siempre a la última. Vivir al límite.
      VERSION: "LATEST"

      # Activamos las flags de Aikar.
      # Créeme, no quieres gestionar el Garbage Collector manualmente.
      USE_AIKAR_FLAGS: "true"

      # Zona horaria (cámbiala a la tuya para no volverte loco con los logs)
      TZ: "America/Santiago"

      # ✨ LA MAGIA:
      # Inyecta las configs optimizadas del repositorio automáticamente al iniciar.
      PAPER_CONFIG_REPO: "https://raw.githubusercontent.com/Alpha018/paper-config-optimized/main"

    volumes:
      - ./minecraft-data:/data

¿Cómo correr esto?

Es tan simple como meter eso en un archivo docker-compose.yml, abrir una terminal en la carpeta y tirar un:

docker compose up -d

⚖️ Balance: Pros y Contras

Como en todo en ingeniería, no hay balas de plata. Esta configuración es mi favorita, pero hay que ser transparentes:

✅ Lo Bueno (Pros)

Velocidad: Pasas de "cero" a "servidor optimizado" en 2 minutos.
Mantenimiento: Al usar PAPER_CONFIG_REPO, si mañana salen nuevas mejoras de rendimiento, solo tienes que reiniciar el contenedor para aplicarlas.
Estabilidad: Usar las Aikar's Flags elimina el 90% de los tirones de lag por culpa de Java.

❌ Lo Malo (Contras)

Caja Negra: Si te gusta ajustar cada milímetro de la view-distance a mano, sentirás que pierdes algo de control (aunque siempre puedes sobrescribir los archivos).
Dependencia: Dependes de que mi repositorio (o el fork que te hagas) esté en línea para descargar las configs al inicio.

🚀 Para Usuarios Avanzados

Esta configuración es ideal para lo que llamo "Survival Técnico Lite". Pero si estás planeando montar una comunidad pública masiva (50+ jugadores) o quieres entender por qué 12GB de RAM es mi número mágico para servidores grandes, escribí una guía técnica mucho más profunda.

☕ Échale un ojo a la Guía Técnica Avanzada en Buy Me a Coffee

💌 Agradecimientos Especiales

A una chica que, sin saberlo, me empujó a seguir creando y programando en mi tiempo libre. A quien alguna vez fue mi chispa: para “YLP”, con gratitud… y con cicatrices que también enseñan.

🚀 Supercarga la Autenticación en NestJS con Firebase

Tomás Alegre Sepúlveda — Sun, 04 Jan 2026 09:13:33 +0000

🇺🇸 Read this post in English

Si vienes del mundo de NestJS, te encantan los decoradores, la inyección de dependencias y el tipado fuerte. Pero cuando se trata de integrar Firebase Authentication, a menudo se siente como una tarea pesada: guards repetitivos, verificación manual de tokens y manejo de roles desordenado que ensucia nuestros controladores.

Hoy quiero reintroducir nestjs-firebase-auth, una librería diseñada para cerrar esa brecha y tratar la autenticación de Firebase con el respeto que merece en una arquitectura moderna de NestJS.

🤔 ¿Por qué creé esto?

Firebase Authentication es robusto, pero el SDK Admin oficial es solo eso: un SDK. No sabe nada sobre Guards, Decoradores o Inyección de Dependencias de NestJS.

No deberías tener que escribir middleware personalizado para decodificar tokens o verificar claims manualmente en cada controlador. nestjs-firebase-auth cierra esta brecha, dándote una API simplificada y declarativa para asegurar tu aplicación.

Con el último lanzamiento v1.9.0, he pulido la experiencia aún más con decoradores más limpios y una mejor integración con otros servicios de Firebase como Firestore.

Instalación

npm install @alpha018/nestjs-firebase-auth firebase-admin

🛠️ Profundizando en el Código

Veamos ejemplos más realistas de lo que puedes lograr.

1. Autenticación Declarativa `(@Auth)`

Olvídate de importar y vincular manualmente los guards con @UseGuards(FirebaseGuard). Ahora tienes un decorador @Auth() limpio que hace clara tu intención.

import { Auth } from '@alpha018/nestjs-firebase-auth';

@Auth() // 🛡️ Protege todo este controlador
@Controller('users')
export class UsersController {

  @Get('profile')
  getProfile() {
    return "Estos datos son seguros.";
  }
}

2. Control de Acceso Basado en Roles (RBAC)

Manejar roles no debería ser complicado. Utilizo los Custom Claims de Firebase para almacenar los roles del usuario, y el decorador @Roles para hacerlos cumplir sin escribir una sola línea de lógica de validación.

import { Auth, Roles } from '@alpha018/nestjs-firebase-auth';

@Controller('admin')
export class AdminController {

  @Auth()
  @Roles('ADMIN', 'SUPERUSER') // ⛔ Solo permite usuarios con estos roles
  @Get('dashboard')
  getDashboard() {
    return "Datos de administración ultra secretos";
  }
}

Nota: El decorador @Roles activa automáticamente la lógica de validación de roles subyacente cuando se usa con @Auth.

3. Integrando con otros servicios de Firebase

¿Necesitas hablar con Firestore o enviar un mensaje FCM específico? Siempre ha sido posible, pero quiero destacar lo fácil que es acceder a la instancia inicializada de admin.app.App directamente desde mi provider.

import { FirebaseProvider } from '@alpha018/nestjs-firebase-auth';
import { getFirestore } from 'firebase-admin/firestore';

@Injectable()
export class UserDataService {
  constructor(private readonly firebaseProvider: FirebaseProvider) {}

  async saveUserData(uid: string, data: any) {
    // 🔥 Usa la instancia de app del módulo de auth para Firestore
    const firestore = getFirestore(this.firebaseProvider.app);
    return firestore.collection('users').doc(uid).set(data);
  }
}

🎯 Mejores Casos de Uso

Aplicaciones SaaS: Donde necesitas autenticación robusta y segura con configuración mínima.
Microservicios: Compartir lógica de autenticación a través de múltiples servicios NestJS fácilmente usando un enfoque de librería compartida.
Sistemas RBAC: Apps que requieren control granular sobre quién puede hacer qué (Admins vs. Usuarios).

⚠️ Trade-offs (Honestidad Ante Todo)

Validación Remota: Por defecto, verifico los roles obteniendo el registro de usuario desde Firebase. Esto asegura que los roles estén siempre actualizados (sin tokens obsoletos), pero incurre en una pequeña latencia de red.
Validación Local: Puedes optar por useLocalRoles: true para validar contra los claims del token ID directamente (cero latencia), pero debes aceptar que los cambios de roles efectivamente se actualizan solo cuando el usuario refresca su token.

💌 Agradecimientos Especiales

Este proyecto ha sido construido con muchas horas de dedicación y amor por el código.

Para una chica que siempre me inspira en silencio, y su sola existencia me incentiva a seguir programando en mis tiempos libres, gracias "YLP".

☕ Apoya el Proyecto

Si encontraste este proyecto útil o interesante, por favor considera apoyarlo:

⭐️ Estrella en GitHub: Es gratis y ayuda a otros a encontrar la librería.
☕ Cómprame un Café: Si quieres ir un paso más allá, puedes hacerlo en buymeacoffee.com/alpha018.

🔗 Pruébalo y Contribuye

Repo: github.com/Alpha018/nestjs-firebase-auth
Autor: dev.to/alpha018

¿Qué piensas? ¿Estás listo para simplificar tu flujo de autenticación? 👇

🚀 NestJS + RedisOM: Elevando el manejo de Estado a otro nivel

Tomás Alegre Sepúlveda — Sat, 03 Jan 2026 21:19:40 +0000

🇺🇸 Read this post in English

Si vienes del mundo de NestJS, amas los decoradores, la inyección de dependencias y el tipado fuerte. Pero cuando toca integrar Redis, a menudo sentimos que retrocedemos 10 años: magic strings, parsers manuales de JSON y comandos low-level que ensucian nuestra lógica de negocio.

Hoy quiero presentarles nestjs-redisom, una librería open-source diseñada para cerrar esa brecha y tratar a Redis con el respeto que se merece en una arquitectura empresarial moderna.

🤔 ¿Por qué creé esto?

Redis ha evolucionado. Ya no es solo un caché key-value. Con Redis Stack (RedisJSON + RediSearch), se ha convertido en una base de datos de documentos en tiempo real increíblemente potente.

Sin embargo, usar estas features desde Node.js suele ser verboso. Redis OM (la librería oficial) ayuda, pero integrarla en NestJS requería mucho boilerplate. nestjs-redisom elimina esa fricción, dándote una experiencia nativa.

Instalación

npm install nestjs-redisom redis-om redis

🛠️ Profundizando en el Código

Veamos ejemplos más realistas de lo que puedes lograr.

1. Modelado de Datos Complejos (Anidados)

No estamos limitados a strings planos. Podemos modelar objetos complejos con validación implícita.

// 1. Definimos una clase anidada
export class Address {
  @Prop({ indexed: true })
  city: string; // Indexado para buscar "Usuarios en Madrid"

  @Prop()
  zipCode: string;
}

// 2. Definimos la Entidad Principal
@Schema()
export class UserProfile extends BaseEntity {
  @Prop({ textSearch: true })
  bio: string;

  @Prop({ type: () => Address }) // Mapeo anidado
  address: Address;

  @Prop()
  roles: string[]; // Arrays de strings
}

2. Búsquedas Avanzadas (Fluent API)

Aquí es donde nestjs-redisom brilla. Olvídate de aprender la sintaxis de comandos de RediSearch (FT.SEARCH index "@field:value ..."). Usa esta API fluida y tipada.

"Encuentra usuarios que vivan en 'New York', tengan el rol 'admin' y cuya bio mencione 'typescript'"

const users = await userRepo.search()
  .where('address_city').equals('New York') // Busca en objeto anidado
  .and('roles').contain('admin')            // Busca en Array
  .and('bio').matches('typescript')         // Full-Text Search
  .return.page(0, 10);                      // Paginación nativa

3. Expiración de Documentos (TTL)

Manejar sesiones o caché temporal es trivial. No necesitas scripts de Lua ni nada por el estilo.

// Crea una sesión y haz que expire en 1 hora
async createSession(user: User) {
  const session = await this.sessionRepo.save(user);
  await this.sessionRepo.expire(session[this.sessionRepo.schema.idField], 3600);
  return session;
}

🎯 Mejores Casos de Uso

High-Speed Objects: Carritos de compra, Perfiles de Jugador, Sesiones. Datos que lees/escribes 1000 veces por segundo.
Caché con "Poderes": A veces necesitas invalidar caché por criterio ("borrar caché de todos los productos de la categoría X"). Con Redis normal es imposible (o lento con KEYS *). Con RedisOM es una query de O(1) o O(N log N).
Geo-Spatial Features: "Encuentra conductores cerca de mi", usando la potencia nativa de Redis para geo-hashing.

⚠️ Trade-offs (Honestidad ante todo)

RAM es Dinero: Redis guarda todo en memoria. No uses esto para guardar logs de auditoría de 5 años.
Eventual Consistency: Los índices de búsqueda se actualizan asíncronamente (milisegundos). No es ACID estricto para búsquedas inmediatas post-escritura.

💌 Agradecimientos Especiales

Este proyecto ha sido construido con muchas horas de dedicación y amor por el código.

Para una chica que siempre me inspira en silencio, y su sola existencia me incentiva a seguir programando en mis tiempos libres, gracias "YLP".

☕ Apoya el Proyecto

Si este proyecto te ha sido útil o te parece interesante, considera apoyarlo:

⭐️ Star en GitHub: Es gratis y ayuda a que más gente lo encuentre.
☕ Invítame un Café: Si quieres ir un paso más allá, puedes hacerlo en buymeacoffee.com/alpha018.

🔗 Pruébalo y Contribuye

Repo: github.com/Alpha018/nestjs-redisom
Autor: dev.to/alpha018

¿Qué opinan? ¿Le darán una oportunidad a Redis como base de datos de documentos? 👇

🚀 NestJS + RedisOM: Taking State Management to the Next Level

Tomás Alegre Sepúlveda — Fri, 02 Jan 2026 01:39:59 +0000

🇪🇸 Lee este post en Español

If you come from the NestJS world, you love decorators, dependency injection, and strong typing. But when it comes to integrating Redis, it often feels like we're stepping back 10 years: magic strings, manual JSON parsers, and low-level commands that clutter our business logic.

Today I want to introduce nestjs-redisom, an open-source library designed to bridge that gap and treat Redis with the respect it deserves in a modern enterprise architecture.

🤔 Why did I create this?

Redis has evolved. It is no longer just a key-value cache. With Redis Stack (RedisJSON + RediSearch), it has become an incredibly powerful real-time document database.

However, using these features from Node.js is often verbose. Redis OM (the official library) helps, but integrating it into NestJS required a lot of boilerplate. nestjs-redisom removes that friction, giving you a native experience.

Installation

npm install nestjs-redisom redis-om redis

🛠️ Deep Dive into the Code

Let's look at more realistic examples of what you can achieve.

1. Complex Data Modeling (Nested)

We aren't limited to flat strings. We can model complex objects with implicit validation.

// 1. Define a Nested Class
export class Address {
  @Prop({ indexed: true })
  city: string; // Indexed to search "Users in Madrid"

  @Prop()
  zipCode: string;
}

// 2. Define the Main Entity
@Schema()
export class UserProfile extends BaseEntity {
  @Prop({ textSearch: true })
  bio: string;

  @Prop({ type: () => Address }) // Nested mapping
  address: Address;

  @Prop()
  roles: string[]; // Array of strings
}

2. Advanced Searching (Fluent API)

This is where nestjs-redisom shines. Forget about learning RediSearch command syntax (FT.SEARCH index "@field:value ..."). Use this fluent, typed API.

"Find users living in 'New York', having the role 'admin', and whose bio mentions 'typescript'"

const users = await userRepo.search()
  .where('address_city').equals('New York') // Search in nested object
  .and('roles').contain('admin')            // Search in Array
  .and('bio').matches('typescript')         // Full-Text Search
  .return.page(0, 10);                      // Native pagination

3. Document Expiration (TTL)

Handling sessions or temporary cache is trivial. You don't need Lua scripts or anything like that.

// Create a session and make it expire in 1 hour
async createSession(user: User) {
  const session = await this.sessionRepo.save(user);
  await this.sessionRepo.expire(session[this.sessionRepo.schema.idField], 3600);
  return session;
}

🎯 Best Use Cases

High-Speed Objects: Shopping Carts, Player Profiles, Sessions. Data you read/write 1000 times per second.
Powered-Up Cache: Sometimes you need to invalidate cache by criteria ("clear cache for all products in category X"). With standard Redis, this is impossible (or slow with KEYS *). With RedisOM, it's an O(1) or O(N log N) query.
Geo-Spatial Features: "Find drivers near me", using Redis native power for geo-hashing.

⚠️ Trade-offs (Honesty First)

RAM is Money: Redis stores everything in memory. Don't use this to store 5 years of audit logs.
Eventual Consistency: Search indexes update asynchronously (milliseconds). It is not strict ACID for immediate post-write searches.

💌 Special Acknowledgments

This project has been built with many hours of dedication and love for code.

To a girl who always inspires me in silence, and whose mere existence incentivizes me to keep programming in my free time, thank you "YLP".

☕ Support the Project

If you found this project useful or interesting, please consider supporting it:

⭐️ Star on GitHub: It's free and helps others find the library.
☕ Buy me a Coffee: If you want to go the extra mile, you can do so at buymeacoffee.com/alpha018.

🔗 Try it and Contribute

Repo: github.com/Alpha018/nestjs-redisom
Author: dev.to/alpha018

What do you think? Will you give Redis a chance as a document database? 👇

🚀 Supercharge NestJS Authentication with Firebase

Tomás Alegre Sepúlveda — Tue, 10 Sep 2024 22:56:14 +0000

🇪🇸 Lee este post en Español

If you're building a modern application with NestJS, you probably love its modularity, decorators, and type safety. But when it comes to authentication, integrating external providers often feels like a chore—boilerplate guards, manual token verification, and messy role handling.

Today, I want to re-introduce nestjs-firebase-auth, a library designed to make Firebase Authentication feel native to the NestJS ecosystem.

🤔 Why this library?

Firebase Authentication is robust, but the official Admin SDK is just that—an SDK. It doesn't know about NestJS Guards, Decorators, or Dependency Injection.

You shouldn't have to write custom middleware to decode tokens or manually check claims in every controller. nestjs-firebase-auth bridges this gap, giving you a simplified, declarative API for securing your application.

With the latest v1.9.0 release, I've polished the experience even further with cleaner decorators and better integration with other Firebase services like Firestore.

Installation

npm install @alpha018/nestjs-firebase-auth firebase-admin

🛠️ Deep Dive into the Code

Let's look at how this changes your daily workflow.

1. Declarative Authentication (`@Auth`)

Forget about manually importing and binding guards with @UseGuards(FirebaseGuard). You now have a clean @Auth() decorator that makes your intention clear.

import { Auth } from '@alpha018/nestjs-firebase-auth';

@Auth() // 🛡️ Protects this entire controller
@Controller('users')
export class UsersController {

  @Get('profile')
  getProfile() {
    return "This data is secure.";
  }
}

2. Role-Based Access Control (RBAC)

Managing roles shouldn't be complicated. I use Firebase Custom Claims to store user roles, and the @Roles decorator to enforce them without writing a single line of validation logic.

import { Auth, Roles } from '@alpha018/nestjs-firebase-auth';

@Controller('admin')
export class AdminController {

  @Auth()
  @Roles('ADMIN', 'SUPERUSER') // ⛔ Only allows users with these roles
  @Get('dashboard')
  getDashboard() {
    return "Top secret admin data";
  }
}

Note: The @Roles decorator automatically triggers the underlying role validation logic when used with @Auth.

3. Type-Safe User Access

Accessing the current user's data is straightforward and type-safe using @FirebaseUser.

@Get('me')
getProfile(@FirebaseUser() user: DecodedIdToken) {
  // `user` is the standard Firebase DecodedIdToken
  console.log(user.uid, user.email);
}

4. Integrating with other Firebase Services

Need to talk to Firestore or send a clear-cut FCM message? It has always been possible, but I want to highlight how easy it is to access the initialized admin.app.App instance directly from my provider.

import { FirebaseProvider } from '@alpha018/nestjs-firebase-auth';
import { getFirestore } from 'firebase-admin/firestore';

@Injectable()
export class UserDataService {
  constructor(private readonly firebaseProvider: FirebaseProvider) {}

  async saveUserData(uid: string, data: any) {
    // 🔥 Use the auth module's app instance for Firestore
    const firestore = getFirestore(this.firebaseProvider.app);
    return firestore.collection('users').doc(uid).set(data);
  }
}

🎯 Best Use Cases

SaaS Applications: Where you need robust, secure authentication with minimal setup.
Microservices: Sharing authentication logic across multiple NestJS services easily using a shared library approach.
RBAC Systems: Apps that require granular control over who can do what (Admins vs. Users).

⚠️ Trade-offs (Honesty First)

Remote Validation: By default, I verify roles by fetching the user record from Firebase. This ensures roles are always up to date (no stale tokens), but it incurs a small network latency.
Local Validation: You can opt-in to useLocalRoles: true to validate against the ID token's claims directly (zero latency), but you must accept that role changes effectively update only when the user refreshes their token.

💌 Special Acknowledgments

This project has been built with many hours of dedication and love for code.

To a girl who always inspires me in silence, and whose mere existence incentivizes me to keep programming in my free time, thank you "YLP".

☕ Support the Project

If you found this project useful or interesting, please consider supporting it:

⭐️ Star on GitHub: It's free and helps others find the library.
☕ Buy me a Coffee: If you want to go the extra mile, you can do so at buymeacoffee.com/alpha018.

🔗 Try it and Contribute

Repo: github.com/Alpha018/nestjs-firebase-auth
Author: dev.to/alpha018

What do you think? Are you ready to simplify your authentication flow? 👇

Forem: Tomás Alegre Sepúlveda

🔬 NestJS vs Go: Performance Benchmark (Do you really need to migrate?)

🏗️ The Scenario

🧪 Methodology: What did we measure?

📊 The Results

1. Small Data: The Surprise

2. Large Data: The Breaking Point

⚖️ Conclusion: When to use which?

✅ Stay with NestJS if:

🚀 Migrate to Go if:

📖 Read the full analysis

🔬 NestJS vs Go: Benchmark de Rendimiento (¿Realmente necesitas migrar?)

🏗️ El Escenario

🧪 Metodología: ¿Qué medimos?

📊 Los Resultados

1. Small Data: La sorpresa

2. Large Data: El punto de quiebre

⚖️ Conclusión: ¿Cuándo usar cuál?

✅ Quédate con NestJS si:

🚀 Migra a Go si:

📖 Lee el análisis completo

💌 Agradecimientos Especiales

🐳 Minecraft + Docker: My personal config to stop suffering with Java

The Initiative: Enough Chaos

"The Recipe" (Configuration)

How to run this?

⚖️ Balance: Pros and Cons

✅ The Good (Pros)

❌ The Bad (Cons)

🚀 For Advanced Users

💌 Special Acknowledgments

🐳 Minecraft + Docker: Mi configuración personal para no sufrir con Java

La Iniciativa: Basta de Caos

"La Receta" (Configuración)

¿Cómo correr esto?

⚖️ Balance: Pros y Contras

✅ Lo Bueno (Pros)

❌ Lo Malo (Contras)

🚀 Para Usuarios Avanzados

💌 Agradecimientos Especiales

🚀 Supercarga la Autenticación en NestJS con Firebase

🤔 ¿Por qué creé esto?

Instalación

🛠️ Profundizando en el Código

1. Autenticación Declarativa (@Auth)

2. Control de Acceso Basado en Roles (RBAC)

3. Integrando con otros servicios de Firebase

🎯 Mejores Casos de Uso

⚠️ Trade-offs (Honestidad Ante Todo)

💌 Agradecimientos Especiales

☕ Apoya el Proyecto

🔗 Pruébalo y Contribuye

🚀 NestJS + RedisOM: Elevando el manejo de Estado a otro nivel

🤔 ¿Por qué creé esto?

Instalación

🛠️ Profundizando en el Código

1. Modelado de Datos Complejos (Anidados)

2. Búsquedas Avanzadas (Fluent API)

3. Expiración de Documentos (TTL)

🎯 Mejores Casos de Uso

⚠️ Trade-offs (Honestidad ante todo)

💌 Agradecimientos Especiales

☕ Apoya el Proyecto

🔗 Pruébalo y Contribuye

🚀 NestJS + RedisOM: Taking State Management to the Next Level

🤔 Why did I create this?

Installation

🛠️ Deep Dive into the Code

1. Complex Data Modeling (Nested)

2. Advanced Searching (Fluent API)

3. Document Expiration (TTL)

🎯 Best Use Cases

⚠️ Trade-offs (Honesty First)

💌 Special Acknowledgments

☕ Support the Project

🔗 Try it and Contribute

🚀 Supercharge NestJS Authentication with Firebase

🤔 Why this library?

Installation

🛠️ Deep Dive into the Code

1. Autenticación Declarativa `(@Auth)`

1. Declarative Authentication (`@Auth`)