8 publicaciones etiquetados con "Node.js"

Elegir multi-tenancy mal el día 1 te cuesta 6 meses de refactor el día 400. Es una de esas decisiones arquitectónicas que parecen inocuas al principio — "solo agregamos un tenantId a todas las tablas" — y que 18 meses después se revelan como la razón por la cual tu SaaS no puede cumplir un requisito de aislamiento de datos de un cliente grande, no puede migrar tenants entre regiones, o no puede ofrecer self-hosted a un cliente que lo exige.

Para un SaaS B2B que arranca en 2026, las dos arquitecturas serias son schema-per-tenant y Row-Level Security (RLS). La tercera opción, "base de datos separada por tenant", se reserva para clientes enterprise con contratos específicos y no es el default. Elegir entre schema-per-tenant y RLS no es técnica pura: es también una decisión de negocio sobre cuántos tenants vas a tener, qué tamaño, y qué compromisos de aislamiento necesitás firmar.

Este post compara ambas con código funcional, benchmarks reales y los criterios de decisión que usamos en MeepLab cuando un cliente nos pregunta "¿cómo hacemos multi-tenancy?". Todo con PostgreSQL puro, Prisma y Express — cero dependencias SaaS de pago ni ORM propietario.

En este artículo aprenderás:

• Los tres modelos de multi-tenancy y cuándo descartás cada uno
• Schema-per-tenant explicado: cómo implementarlo en PostgreSQL, fuerzas y límites operacionales
• Row-Level Security con PostgreSQL: CREATE POLICY, middleware Express y cómo funciona internamente
• Benchmark real de ambos patrones con 100 tenants y 10M filas
• Criterios de decisión: 8 preguntas que respondés antes de elegir
• Cuándo migrar de un modelo al otro y cuánto cuesta

prisma migrate deploy en una tabla de 50 millones de registros es decir "qué podría salir mal" en producción. Esa migración tan inocente que localmente tomó 200 milisegundos, en producción con un índice que se reconstruye, una columna que se llena con default, y requests concurrentes golpeando la misma tabla, puede tomar 40 minutos de lock exclusivo. Cuarenta minutos durante los cuales ningún usuario puede loguearse, ningún pago se procesa, y el canal de Slack de operaciones se llena de capturas de pantalla de errores 500.

El problema no es Prisma. Es cualquier migración naive contra una tabla grande en producción. Postgres y MySQL tienen operaciones que bloquean la tabla completa mientras corren: agregar una columna con default no nullable, cambiar el tipo de una columna, renombrar algo que está referenciado. Si corrés esas operaciones contra una tabla de millones de filas y un load balancer que no para de mandar tráfico, el sistema se congela.

El patrón que resuelve esto no es nuevo. Se llama expand-contract (también conocido como parallel change) y es la técnica estándar que usan equipos como GitHub, Shopify y Stripe para cambiar esquemas sin cortar el servicio. La idea: cada migración se divide en cuatro fases pequeñas que individualmente son seguras, corren en segundos, y se pueden desplegar gradualmente con feature flags.

En este artículo aprenderás:

• Qué operaciones bloquean la tabla en PostgreSQL y cuáles no (la lista corta y exacta)
• El patrón expand-contract en 4 fases: Expand → Migrate → Contract → Cleanup, con ejemplo real en Prisma
• Backfill batched para mover datos de una columna vieja a una nueva sin saturar la base de datos
• Rollback seguro en cada fase si algo falla a mitad del deploy
• Checklist de migración que usamos antes de tocar producción

Datadog te cobra 31 dólares por host. Tu startup de 12 servicios acaba de gastar runway en logs antes de facturar al primer cliente. Y la peor parte no es el precio: es que la mayoría de los equipos que pagan por un SaaS de observabilidad carísimo no entienden qué están midiendo. Pagan por dashboards que nadie abre, por alertas que todos silencian, y por retention de 30 días de datos que nunca consultan.

Auditoría técnica real de un backend Node.js de PyME no necesita un contrato enterprise de Datadog. Necesita responder a 12 preguntas específicas que revelan la madurez operacional del sistema. Las hemos estandarizado en el health-check que corremos antes de aceptar un cliente de backend: si el sistema falla en más de 4 de esas 12, la conversación cambia de "optimizamos" a "reconstruimos la capa de observabilidad antes de tocar la lógica de negocio".

Todo el stack que cubrimos es open source, se autohospeda en un VPS de 20 dólares al mes, y reemplaza el 90% de las funciones de Datadog/New Relic para el tamaño de operación típico de una PyME. No es un ejercicio académico: es el stack que corremos nosotros mismos.

En este artículo aprenderás:

• Las 12 señales del health-check que auditamos en cualquier backend Node.js: logs, traces, métricas, errores, latencia y más
• Stack OSS completo: OpenTelemetry + Prometheus + Grafana + Loki + Tempo, con docker-compose.yml funcional
• Qué instrumentar primero si solo tienes 2 horas antes de la próxima reunión con el CFO
• Alertas mínimas que cualquier backend en producción debería tener antes de dormir tranquilo
• Cuándo sí conviene un SaaS pagado — y cuándo es desperdicio de dinero

Tu webhook que "a veces falla" no falla a veces. Falla siempre que importa. Cuando el evento es una confirmación de pago de Stripe que el usuario ya vio en pantalla, cuando es un acuse del SAT que te notifica que el CFDI pasó a timbrado, cuando es un cambio de status de un envío que el cliente está esperando. En esos momentos tu receptor de webhooks está ocupado, la base de datos está lenta, o un deploy reciente rompió una ruta, y pierdes el evento. El emisor reintenta dos o tres veces con suerte, después te marca como "endpoint no confiable" y abandona.

Recibir webhooks bien no es tener un POST /webhook que responde 200. Es aceptar el evento en menos de 5 segundos sin importar qué, validar la firma, evitar procesar el mismo evento dos veces si llega duplicado, y procesarlo en background con reintentos exponenciales cuando falla. Todo eso se puede hacer con Node.js, Redis y BullMQ en menos de 300 líneas de TypeScript.

En este artículo aprenderás:

• Por qué los webhooks fallan en producción y qué contrato implícito tiene tu endpoint con cada emisor
• Patrón receive-fast-process-async con BullMQ para aceptar el evento en menos de 1 segundo
• Firma HMAC SHA-256 implementada bien, con comparación resistente a timing attacks
• Idempotencia por idempotency-key con Redis para no procesar el mismo evento dos veces
• Retries con backoff exponencial y Dead Letter Queue para los eventos que fallan persistentemente
• Ejemplo real con SAT PAC y Stripe para aterrizar los patrones en casos conocidos

Poner express-rate-limit en tu API no es rate limiting. Es teatro de seguridad. Si tu backend corre en dos o más instancias detrás de un load balancer, cada réplica cuenta requests por separado y tu "límite de 100 req/min" se convierte en 200, 400 o 1,000 según cuántos pods escales. El atacante no nota la diferencia. Tu base de datos sí.

El rate limiting serio vive fuera del proceso: en un almacén compartido que todas las réplicas consultan de forma atómica. Ese almacén, en la práctica, es Redis. Y el algoritmo correcto casi nunca es el contador fijo que viene por defecto en las librerías populares: es el sliding window log, que cuesta más en memoria pero no deja ventanas de abuse entre segundos.

En este artículo aprenderás:

• Por qué express-rate-limit con memoria local falla en arquitecturas con más de una instancia
• Los tres algoritmos clásicos (fixed window, sliding window log, token bucket) explicados con sus trade-offs reales
• Implementación paso a paso de sliding window log con ioredis y TypeScript, con operaciones atómicas
• Cómo medir si funciona usando autocannon para simular ráfagas y ver cuándo se rompe
• Checklist de producción con los errores que hemos visto en auditorías reales a APIs Node.js

El 80% de las brechas de seguridad en aplicaciones web involucran credenciales comprometidas o autenticación mal implementada (Verizon Data Breach Report, 2025). No estamos hablando de ataques sofisticados de estado-nación. Estamos hablando de tokens que nunca expiran, secrets hardcodeados en el código fuente y refresh tokens almacenados en localStorage donde cualquier script de terceros puede leerlos.

La autenticación es el pilar de seguridad más crítico de tu aplicación. Si falla, todo lo demás es irrelevante: tu base de datos cifrada, tu firewall, tus políticas de CORS. Un token JWT mal implementado es una puerta abierta.

En este artículo aprenderás:

• Cómo funciona JWT internamente: anatomía del token, firma y verificación
• Configuración completa del proyecto con Express, TypeScript y las dependencias correctas
• Registro y login seguros con hash de contraseñas usando bcrypt
• Middleware de autenticación para proteger rutas y extraer información del usuario
• Refresh tokens con rotación para sesiones seguras de larga duración
• Mejores prácticas de seguridad que separan un proyecto hobby de uno de producción

Según la encuesta de Stack Overflow 2024, Node.js es la tecnología de backend más usada por segundo año consecutivo, y TypeScript superó a JavaScript como lenguaje preferido para proyectos nuevos. Si tu equipo está construyendo un backend en 2026, esta es la combinación que probablemente van a usar.

Pero hay una diferencia enorme entre una API que "funciona" y una API que tu equipo puede mantener, escalar y debugear a las 3 de la mañana cuando algo falla en producción.

En este artículo aprenderás:

• La estructura de carpetas que escala de 5 a 50 endpoints sin volverse caótica
• Cómo configurar TypeScript para máxima productividad sin frustración
• Patrones de validación, errores y middleware que todo equipo necesita
• Testing desde el inicio: cómo escribir tests que realmente protegen tu código
• Buenas prácticas que separan un proyecto hobby de uno profesional
• Cuándo esta arquitectura es suficiente y cuándo necesitas algo más robusto

El 72% de las empresas planean integrar inteligencia artificial en sus productos durante 2026 (McKinsey, 2025). Pero la mayoría no sabe por dónde empezar. La buena noticia: integrar un LLM (Large Language Model) a tu aplicación Node.js no requiere un equipo de data science. Requiere entender la arquitectura correcta y unas cuantas decenas de líneas de código.

En este artículo aprenderás:

• Cómo funciona la integración de un LLM a nivel de arquitectura
• Qué proveedor elegir (OpenAI, Anthropic, Google) según tu caso
• Código funcional para conectar tu aplicación con un LLM
• Patrones de producción: streaming, manejo de errores, rate limiting
• Cuánto cuesta realmente operar un LLM en tu aplicación
• Errores comunes que pueden salir caros en producción