DEV Community: Juan Torchia

Rate limiting in web apps: what to protect before picking a library

Juan Torchia — Fri, 05 Jun 2026 12:02:54 +0000

Rate limiting in web apps: what to protect before picking a library

I made the mistake of adding rate limiting like it was a convenience dependency — npm install, copy middleware from a tutorial, paste the magic number of 100 requests per minute, and get back to the sprint. I did it because "security" was on the backlog and I wanted to tick the box. The result was predictable: the middleware existed, but it wasn't protecting anything in particular. And the first time I actually looked at the logs with fresh eyes, I realized I had no idea what would have happened if someone had abused the login endpoint.

I'm telling you this because that exact pattern is what I keep seeing recycled in Next.js tutorials: install a library, wrap it as global middleware, call it "security." That's not security. That's security vibes.

My take is concrete: rate limiting isn't a dependency; it's an abuse policy. And a policy without a definition is a rule without a subject.

What rate limiting in Next.js actually is — and what it isn't

Rate limiting is a mechanism to reject or delay requests that exceed a defined threshold within a time window. That's all it is, technically. The real value isn't in the threshold — it's in the decision that led to that threshold.

OWASP, in its Authentication Cheat Sheet, recommends specific defensive controls around authentication: temporary account lockout after failed attempts, progressive throttling, and uniform responses to avoid leaking whether a user exists. What OWASP does not say is "install library X and set 100 req/min on all routes." That's an interpretation, not a prescription.

The difference matters: the OWASP guide gives you the what to protect (authentication, password recovery, endpoints that expose account state). The concrete implementation depends on your stack, your traffic, and the cost you're willing to absorb when you block a legitimate user.

In Next.js App Router, the natural interception point is Middleware (middleware.ts), which runs at the edge before the request reaches the route — I covered that in detail in this post on authorization patterns in Next.js 16 Middleware. But the execution layer doesn't replace the policy; it just enforces it.

The classic mistake: copying middleware before defining the asset

The typical tutorial starts like this:

// middleware.ts — example of what NOT to do first
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(100, "1 m"), // why 100? why 1 minute?
});

export async function middleware(request: NextRequest) {
  const ip = request.ip ?? "127.0.0.1";
  const { success } = await ratelimit.limit(ip);
  if (!success) return new NextResponse("Too Many Requests", { status: 429 });
  return NextResponse.next();
}

export const config = {
  matcher: ["/((?!_next|favicon.ico).*)"], // applies to EVERYTHING — really?
};

The code works. The problem is the chain of unanswered questions:

Why 100 requests per minute? Based on what measured legitimate behavior?
Does applying it to every route even make sense? A static image and a login endpoint don't share the same abuse profile.
What happens to a legitimate user behind a corporate proxy or a university network where dozens of people share the same IP?
Is there a log of the 429 that lets you tell the difference between a real attack and a false positive?

None of those questions get answered by the library. You answer them before you touch the code.

The decision matrix: four questions before writing a single line

Before choosing an algorithm, a library, or a threshold, these four questions determine whether the rate limiting you're about to implement actually makes sense:

1. What asset are you protecting?

Not "the app." Something concrete:

Asset	Why limiting it matters
Login endpoint	Credential stuffing, brute force
Password recovery endpoint	Account enumeration, email spam
Form submission API	Spam, notification flooding
Expensive search endpoint	Compute resource abuse
Static routes / assets	Probably not — leave it to the CDN

OWASP explicitly calls out the first two. The rest are product decisions that you have to make.

2. What abuse are you expecting?

The abuse you want to limit determines the right algorithm:

High-velocity credential stuffing: sliding window with a low per-IP threshold on the auth endpoint.
Slow, distributed scraping: IP alone isn't enough — you need fingerprinting or session tokens.
Automated form spam: CAPTCHA first, rate limiting as a second layer.
Legitimate traffic spikes (launch day, going viral): aggressive rate limiting can hurt you here — consider queueing or backpressure first.

If you don't know what abuse you're expecting, whatever threshold you set is arbitrary. And an arbitrary threshold is just as likely to annoy real users as it is to stop someone with actual malicious intent.

3. What does a false positive cost you?

This is the cost tutorials always skip. A 429 hitting a legitimate user has real consequences that depend on context:

In a SaaS with paying customers: lost trust, churn, a support ticket.
In a public app with anonymous users: frustration, abandonment.
In an internal API: it can silently break a critical flow.

The cost of a false positive defines how tight you can make the threshold. If the cost is high, you need a more permissive threshold and better abuse signals (user-agent, behavioral patterns, tokens) instead of just IP.

4. How do you observe that it's working?

If you don't have an answer to this, what you implemented is decorative security. A rate limiter without observability won't tell you whether it's blocking real abuse or legitimate users, whether the threshold is too aggressive or too permissive, or whether someone is already bypassing the control with a different technique.

The useful minimum is logging every 429 with:

Timestamp
IP (or whatever identifier you use as the key)
Affected route
Authentication context if available (authenticated user vs. anonymous)

// middleware.ts — version with minimal observability
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

// Reproducible example using in-memory storage (dev only or edge with local state)
// In real production you need Redis or another distributed store
const attempts = new Map<string, { count: number; reset: number }>();

const LIMIT = 10; // only for the login endpoint
const WINDOW_MS = 60_000; // 1 minute

export async function middleware(request: NextRequest) {
  // Only applying to the login route — defined asset, not global
  if (!request.nextUrl.pathname.startsWith("/api/auth/login")) {
    return NextResponse.next();
  }

  const ip = request.headers.get("x-forwarded-for")?.split(",")[0] ?? "unknown";
  const now = Date.now();
  const record = attempts.get(ip);

  if (!record || now > record.reset) {
    attempts.set(ip, { count: 1, reset: now + WINDOW_MS });
    return NextResponse.next();
  }

  record.count++;

  if (record.count > LIMIT) {
    // Observable log: in production this goes to your logging system
    console.warn(JSON.stringify({
      event: "rate_limit_exceeded",
      ip,
      route: request.nextUrl.pathname,
      attempts: record.count,
      timestamp: new Date().toISOString(),
    }));

    return new NextResponse(
      JSON.stringify({ error: "Too many attempts. Wait a moment." }),
      {
        status: 429,
        headers: {
          "Content-Type": "application/json",
          "Retry-After": "60",
        },
      }
    );
  }

  return NextResponse.next();
}

export const config = {
  // Only intercept the route we defined as the asset
  matcher: ["/api/auth/login"],
};

⚠️ This example uses an in-memory Map, which doesn't persist across edge runtime instances and doesn't survive a redeploy. For production on Railway or any other distributed environment, you need an external store like Redis (Upstash, Redis Cloud). This example is a decision pattern, not a production recipe.

Where people get it wrong: three patterns that look right but aren't

Pattern 1: Global rate limiting as a substitute for endpoint security

A middleware that caps all routes at 100 req/min doesn't protect the login endpoint any better than no rate limiting at all — if the threshold is above the volume of a typical brute-force attack. The attacker just respects the limit and keeps going. What actually helps is a low, specific threshold on the right asset — closer to what OWASP recommends for authentication.

Pattern 2: IP as the only key dimension

A user behind CGNAT (IPv4 shared across thousands of people) has the same IP as everyone else on that network. In corporate or university contexts, rate limiting them all together can block dozens of legitimate people because of one person's behavior. If the asset you're protecting is primarily accessed by authenticated users, the key should be the user or session identifier, not the IP.

Pattern 3: Forgetting the Retry-After header

RFC 6585 defines that a 429 response should include a Retry-After header indicating how long the client should wait. Without that header, automated clients — SDKs, mobile apps, integrations — will retry immediately and make the problem you were trying to limit worse. Small detail, concrete consequences.

Limits of this guide: what you can't conclude without your own data

There are things I'm not going to claim here because they depend on context I don't have:

What threshold to use: there's no universally correct number. The 10 req/min in the login example is illustrative. The real number comes from measured legitimate behavior in production — or a conservative initial decision with room to adjust.
Whether Upstash, Redis Cloud, or something else is better: that depends on latency from where you run the edge, cost per operation, and the operational complexity you're willing to maintain.
Whether rate limiting solves slow, distributed scraping: probably not, at least not alone. That scenario needs other signals. Claiming otherwise without data would be selling an incomplete solution to someone with a real problem.

Before assuming your rate limiting is working, you need real logs. Without them, the control exists on paper but not in practice.

FAQ: rate limiting in Next.js web applications

Where do I implement rate limiting in Next.js App Router — in Middleware or in the Route Handler?

Depends on the asset. If you want to act before the request reaches the route logic (and before compute costs kick in), Middleware is the right place. If you need full authentication context or business logic to decide the limit, the Route Handler has more information. In practice, both layers can coexist: Middleware for coarse IP-level limits, Route Handler for fine-grained per-authenticated-user limits.

Can I use an in-memory Map as the store for the rate limiter?

Only in development or as a pattern demonstration. An in-memory Map isn't shared across instances (Next.js can have multiple workers) and resets on every redeploy. For a distributed environment like Railway or Vercel, you need an external store — Redis is the most common and well-documented option.

Does rate limiting replace CAPTCHA on the login form?

No. They're different controls. CAPTCHA aims to distinguish humans from bots in real time. Rate limiting aims to cap the volume of attempts regardless of whether they're human or bot. OWASP suggests both as complementary layers, not as alternatives.

What happens if a legitimate user hits the limit by accident?

They should get a 429 with a clear Retry-After and an understandable message. If that happens frequently, the threshold is miscalibrated for legitimate traffic — that's a signal to revisit the number, not to remove the control.

Is rate limiting enough to protect a public API from mass scraping?

Probably not, if the scraping is distributed (many different IPs, each with low volume). Per-IP rate limiting only works well against high-frequency concentrated sources. Distributed scraping needs other signals: user-agent fingerprinting, behavioral pattern analysis, or mandatory token-based authentication.

Should I apply rate limiting to static asset routes?

Generally no — that's work for a CDN or the infrastructure layer. Applying rate limiting to /favicon.ico or images from Next.js Middleware adds latency with no real defensive benefit. If asset traffic is the problem, the right control is at the network layer, not the application.

The library doesn't decide the policy. You do.

There's a reason misconfigured rate limiting is worse than none: it gives you the feeling that the asset is protected when it isn't, or it protects something that doesn't matter while leaving the thing that does matter wide open.

My position: before installing any library, answer the four questions in the matrix. If you can't answer "what asset am I protecting" and "what abuse am I expecting" with something more specific than "the app" and "bad people," you're not ready to implement the policy. You're ready to copy a tutorial.

The concrete next step: look at your authentication routes first. They're the ones OWASP flags with the most evidence of needing controls. Define a conservative threshold, add minimal observability (log those 429s), and check those logs in the first 48 hours. That's where you'll get real data to calibrate against.

If you want to understand how Next.js Middleware executes these controls and what happens with race conditions at scale, the post on authorization patterns in Next.js 16 Middleware is the logical next step. And if backend endpoint security is part of the picture, it's worth crossing with what I covered on what to expose and what to hide in Spring Boot Actuator.

Primary source:

OWASP Authentication Cheat Sheet — defensive controls around authentication and abuse: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

This article was originally published on juanchi.dev

Rate limiting en aplicaciones web: qué proteger antes de elegir una librería

Juan Torchia — Fri, 05 Jun 2026 12:02:49 +0000

Rate limiting en aplicaciones web: qué proteger antes de elegir una librería

Cometí el error de agregar rate limiting como si fuera una dependencia de conveniencia — npm install, copiar middleware de un tutorial, pegar el número mágico de 100 requests por minuto y seguir con el sprint. Lo hice porque "seguridad" estaba en el backlog y quería tildar el ítem. El resultado fue predecible: el middleware existía, pero no protegía nada en particular. Y la primera vez que revisé los logs con criterio, me di cuenta de que no sabía qué habría pasado si alguien hubiera abusado del endpoint de login.

Lo cuento porque ese patrón es exactamente el que veo circular en tutoriales de Next.js: instalar una librería, enrollarla como middleware global y llamarle "seguridad". No es seguridad. Es vibra de seguridad.

Mi tesis es concreta: rate limiting no es una dependencia; es una política de abuso. Y una política sin definición es una regla sin sujeto.

Qué es rate limiting en aplicaciones web con Next.js — y qué no es

Rate limiting es un mecanismo para rechazar o demorar solicitudes que superan un umbral definido en una ventana de tiempo. Eso es todo lo que es a nivel técnico. El valor real no está en el umbral — está en la decisión que llevó a ese umbral.

OWASP, en su Authentication Cheat Sheet, recomienda controles defensivos específicos alrededor de autenticación: bloqueo temporal de cuenta tras intentos fallidos, throttling progresivo y respuestas uniformes para no revelar si el usuario existe. Lo que OWASP no dice es "instalá X librería y configurá 100 req/min en todas las rutas". Eso es una interpretación, no una prescripción.

La diferencia importa: la guía de OWASP te da el qué proteger (autenticación, recuperación de contraseña, endpoints que exponen estado de cuenta). La implementación concreta depende de tu stack, tu tráfico y el costo que estás dispuesto a asumir cuando bloqueás a alguien legítimo.

En Next.js App Router, el lugar natural para interceptar es el Middleware (middleware.ts), que corre en el edge antes de que el request llegue a la ruta — lo analicé en detalle en este post sobre patrones de autorización en Next.js 16 Middleware. Pero la capa de ejecución no reemplaza la política; solo la aplica.

El error clásico: copiar el middleware antes de definir el activo

El tutorial típico empieza así:

// middleware.ts — ejemplo de lo que NO hacer primero
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(100, "1 m"), // ¿por qué 100? ¿por qué 1 minuto?
});

export async function middleware(request: NextRequest) {
  const ip = request.ip ?? "127.0.0.1";
  const { success } = await ratelimit.limit(ip);
  if (!success) return new NextResponse("Too Many Requests", { status: 429 });
  return NextResponse.next();
}

export const config = {
  matcher: ["/((?!_next|favicon.ico).*)"], // aplica a TODO — ¿seguro?
};

El código funciona. El problema es la cadena de preguntas sin responder:

¿Por qué 100 requests por minuto? ¿Basado en qué comportamiento legítimo medido?
¿Aplicarlo a todas las rutas tiene sentido? Una imagen estática y un endpoint de login no tienen el mismo perfil de abuso.
¿Qué le pasa a un usuario legítimo detrás de un proxy corporativo o una red universitaria donde muchos comparten la misma IP?
¿Hay un log del 429 que permita distinguir ataque real de falso positivo?

Ninguna de esas preguntas la resuelve la librería. Las resolvés vos antes de tocar el código.

La matriz de decisión: cuatro preguntas antes de escribir una línea

Antes de elegir algoritmo, librería o umbral, estas cuatro preguntas definen si el rate limiting que vas a implementar tiene sentido:

1. ¿Qué activo protegés?

No "la app". Algo concreto:

Activo	Por qué importa limitarlo
Endpoint de login	Credential stuffing, fuerza bruta
Endpoint de recuperación de contraseña	Enumeración de cuentas, spam de emails
API de envío de formularios	Spam, flood de notificaciones
Endpoint de búsqueda costosa	Abuso de recursos de cómputo
Rutas estáticas / assets	Probablemente no — dejalo a CDN

OWASP señala explícitamente los dos primeros. Los otros son decisiones de producto que vos tenés que tomar.

2. ¿Qué abuso esperás?

El abuso que querés limitar determina el algoritmo correcto:

Credential stuffing de alta velocidad: sliding window con umbral bajo por IP en el endpoint de auth.
Scraping lento y distribuido: IP sola no alcanza — necesitás fingerprinting o tokens de sesión.
Spam de formularios automatizado: CAPTCHA primero, rate limiting como segunda capa.
Picos de tráfico legítimo (lanzamiento, viral): rate limiting estricto puede hacerte daño — considerá queueing o backpressure primero.

Si no sabés qué abuso esperás, el umbral que ponés es arbitrario. Y un umbral arbitrario tiene la misma probabilidad de molestar a usuarios reales que de detener a alguien con intención maliciosa.

3. ¿Cuánto te cuesta un falso positivo?

Este es el costo que los tutoriales omiten. Un 429 a un usuario legítimo tiene consecuencias reales que dependen del contexto:

En un SaaS con clientes pagos: pérdida de confianza, churn, ticket de soporte.
En una app pública con usuario anónimo: frustración, abandono.
En una API interna: puede romper un flujo crítico silenciosamente.

El costo del falso positivo define cuánto podés apretar el umbral. Si el costo es alto, necesitás un umbral más permisivo y mejores señales de abuso (user-agent, comportamiento, tokens) en lugar de solo IP.

4. ¿Cómo observás que está funcionando?

Si no tenés respuesta para esto, lo que implementaste es seguridad decorativa. Un rate limiter sin observabilidad no te dice si está bloqueando abuso real o usuarios legítimos, si el umbral es demasiado agresivo o demasiado permisivo, ni si alguien está evadiendo el control con otra técnica.

El mínimo útil es loggear cada 429 con:

Timestamp
IP (o identificador que uses como clave)
Ruta afectada
Contexto de autenticación si está disponible (usuario autenticado vs. anónimo)

// middleware.ts — versión con observabilidad mínima
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

// Ejemplo reproducible con almacenamiento en memoria (solo para desarrollo o edge con estado local)
// En producción real necesitás Redis u otro store distribuido
const intentos = new Map<string, { count: number; reset: number }>();

const LIMITE = 10; // solo para el endpoint de login
const VENTANA_MS = 60_000; // 1 minuto

export async function middleware(request: NextRequest) {
  // Solo aplicamos a la ruta de login — activo definido, no global
  if (!request.nextUrl.pathname.startsWith("/api/auth/login")) {
    return NextResponse.next();
  }

  const ip = request.headers.get("x-forwarded-for")?.split(",")[0] ?? "desconocida";
  const ahora = Date.now();
  const registro = intentos.get(ip);

  if (!registro || ahora > registro.reset) {
    intentos.set(ip, { count: 1, reset: ahora + VENTANA_MS });
    return NextResponse.next();
  }

  registro.count++;

  if (registro.count > LIMITE) {
    // Log observable: en producción esto iría a tu sistema de logs
    console.warn(JSON.stringify({
      evento: "rate_limit_excedido",
      ip,
      ruta: request.nextUrl.pathname,
      intentos: registro.count,
      timestamp: new Date().toISOString(),
    }));

    return new NextResponse(
      JSON.stringify({ error: "Demasiados intentos. Esperá un momento." }),
      {
        status: 429,
        headers: {
          "Content-Type": "application/json",
          "Retry-After": "60",
        },
      }
    );
  }

  return NextResponse.next();
}

export const config = {
  // Solo interceptamos la ruta que definimos como activo
  matcher: ["/api/auth/login"],
};

⚠️ Este ejemplo usa Map en memoria, que no persiste entre instancias del edge runtime ni sobrevive un redeploy. Para producción sobre Railway u otro entorno distribuido, necesitás un store externo como Redis (Upstash, Redis Cloud). El ejemplo sirve como patrón de decisión, no como receta de producción directa.

Dónde se equivoca la gente: tres patrones que parecen bien pero no lo son

Patrón 1: Rate limiting global como sustituto de seguridad de endpoint

Un middleware que limita todas las rutas a 100 req/min no protege el endpoint de login mejor que uno sin rate limiting, si el umbral está por encima del volumen de un ataque de fuerza bruta típico. El atacante simplemente respeta el límite y sigue. Lo que realmente ayuda es un umbral bajo y específico en el activo correcto — más en la línea de lo que recomienda OWASP para autenticación.

Patrón 2: IP como única dimensión de clave

Un usuario detrás de CGNAT (IPv4 compartida entre miles) tiene la misma IP que otro. En contextos corporativos o educativos, limitarlos a todos juntos puede bloquear a decenas de personas legítimas por el comportamiento de una sola. Si el activo que protegés es accedido principalmente por usuarios autenticados, la clave debería ser el identificador de usuario o sesión, no la IP.

Patrón 3: Olvidar el header Retry-After

RFC 6585 define que una respuesta 429 debería incluir el header Retry-After indicando cuánto debe esperar el cliente. Sin ese header, clientes automáticos (SDKs, apps móviles, integraciones) van a reintentar inmediatamente y agravar el problema que intentabas limitar. Es un detalle pequeño con consecuencias concretas.

Límites de esta guía: qué no podés concluir sin datos propios

Hay cosas que no voy a afirmar acá porque dependen de contexto que no tengo:

Qué umbral usar: no existe un número correcto universal. El 10 req/min del ejemplo de login es ilustrativo. El número real lo define el comportamiento legítimo medido en producción — o una decisión conservadora inicial con capacidad de ajuste.
Si Upstash, Redis Cloud u otro store es mejor: dependen de la latencia desde donde corrés el edge, el costo por operación y la complejidad operativa que estás dispuesto a mantener.
Si el rate limiting resuelve scraping lento y distribuido: probablemente no, al menos no solo. Ese escenario requiere otras señales. Afirmar lo contrario sin datos sería venderle una solución incompleta a alguien con un problema real.

Antes de asumir que el rate limiting funciona, necesitás logs reales. Sin ellos, el control existe en papel pero no en práctica.

FAQ: rate limiting en aplicaciones web con Next.js

¿Dónde implemento rate limiting en Next.js App Router — en Middleware o en la Route Handler?

Depende del activo. Si querés actuar antes de que el request llegue a la lógica de la ruta (y antes de costos de compute), el Middleware es el lugar correcto. Si necesitás contexto de autenticación completo o lógica de negocio para decidir el límite, la Route Handler tiene más información. En la práctica, los dos capas pueden coexistir: Middleware para límites gruesos por IP, Route Handler para límites finos por usuario autenticado.

¿Puedo usar un Map en memoria como store para el rate limiter?

Solo en desarrollo o como demostración de patrón. Un Map en memoria no se comparte entre instancias (Next.js puede tener múltiples workers) y se reinicia con cada redeploy. Para un ambiente distribuido como Railway o Vercel, necesitás un store externo — Redis es la opción más común y documentada.

¿El rate limiting reemplaza CAPTCHA en el formulario de login?

No. Son controles diferentes. CAPTCHA apunta a distinguir humanos de bots en tiempo real. Rate limiting apunta a limitar el volumen de intentos independientemente de si son humanos o bots. OWASP sugiere los dos como capas complementarias, no como alternativas.

¿Qué pasa si un usuario legítimo toca el límite por error?

Debería recibir un 429 con un Retry-After claro y un mensaje entendible. Si eso pasa frecuentemente, el umbral está mal calibrado para el tráfico legítimo — eso es una señal para revisar el número, no para eliminar el control.

¿Rate limiting alcanza para proteger una API pública de scraping masivo?

Probablemente no, si el scraping es distribuido (muchas IPs distintas con volumen bajo cada una). El rate limiting por IP solo funciona bien contra fuentes de alta frecuencia concentradas. Scraping distribuido requiere otras señales: fingerprinting de user-agent, análisis de patrones de comportamiento o autenticación obligatoria con tokens.

¿Conviene aplicar rate limiting a rutas de assets estáticos?

Generalmente no — eso es trabajo para un CDN o para la capa de infraestructura. Aplicar rate limiting a /favicon.ico o a imágenes desde el Middleware de Next.js agrega latencia sin beneficio defensivo real. Si el tráfico de assets es el problema, el control adecuado está en la capa de red, no en la aplicación.

Cierre: la librería no decide la política, vos sí

Hay una razón por la que el rate limiting mal configurado es peor que ninguno: da la sensación de que el activo está protegido cuando no lo está, o protege algo que no importa mientras deja desprotegido lo que sí importa.

Mi postura es esta: antes de instalar cualquier librería, respondé las cuatro preguntas de la matriz. Si no podés responder "qué activo protejo" y "qué abuso espero" con algo más específico que "la app" y "gente maliciosa", no estás lista para implementar la política. Estás para copiar un tutorial.

El próximo paso concreto: revisá tus rutas de autenticación primero. Son las que OWASP marca con más evidencia de necesitar control. Definí un umbral conservador, agregá observabilidad mínima (loggear los 429) y revisá esos logs en las primeras 48 horas. Ahí vas a tener datos reales para calibrar.

Si querés entender mejor cómo el Middleware de Next.js ejecuta estos controles y qué pasa con los race conditions cuando escala, el post sobre patrones de autorización en Next.js 16 Middleware es el siguiente paso lógico. Y si la seguridad de endpoints de backend es parte del contexto, vale cruzar con lo que cubrí sobre qué exponer y qué ocultar en Spring Boot Actuator.

Fuente original:

OWASP Authentication Cheat Sheet — controles defensivos alrededor de autenticación y abuso: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

Este artículo fue publicado originalmente en juanchi.dev

Next.js 16 Middleware: authorization patterns that scale and the ones that cause race conditions

Juan Torchia — Thu, 04 Jun 2026 12:02:09 +0000

Next.js 16 Middleware: authorization patterns that scale and the ones that cause race conditions

Next.js middleware is basically the bouncer at a club. It doesn't decide if you're welcome inside — that's the staff's job. But it does decide whether you get through the door. And if the bouncer starts running a full background check on every person before opening up, the line wraps around the block.

That's exactly the problem with authorization patterns in Next.js 16 Middleware. Most of the examples floating around online assume you can do full token validation at the edge. The reality is more uncomfortable: the edge runtime has concrete restrictions, and several patterns that worked fine in v14 blow up in production in ways that aren't obvious.

My thesis: Next.js 16 middleware is powerful, but its strength is in verifying session, not in validating a complete token. When you confuse those two roles, you end up with race conditions or latency you don't understand until you're staring at logs at 11pm.

The real problem: edge runtime is not Node.js

Before looking at each pattern, there's one fact that shapes everything that follows: Next.js middleware runs on edge runtime, not full Node.js. That's not a minor detail — it's the reason certain patterns fail.

The edge runtime has access to standard web APIs (Request, Response, Headers, crypto.subtle) but does not have access to:

fs — no reading files
native Node.js modules
libraries that depend on Node buffers or system APIs

What this means for auth is concrete: if your JWT library uses jsonwebtoken with Node's crypto, it won't work in middleware. You need jose or another library compatible with the Web Crypto API.

// ❌ This blows up in edge runtime
import jwt from 'jsonwebtoken' // depends on Node's crypto

// ✅ This works in edge runtime
import { jwtVerify } from 'jose' // Web Crypto API compatible

The official Next.js Middleware docs mention this, but between all the code examples it's easy to skip over that part — until the error shows up in your deploy.

The 4 patterns: tradeoff analysis

Pattern 1 — Full token validation in middleware

The most tempting one and the most problematic.

The idea: grab the token from the cookie or Authorization header, cryptographically verify it in middleware, and decide whether the user gets through.

// middleware.ts
import { jwtVerify } from 'jose'
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

const SECRET = new TextEncoder().encode(process.env.JWT_SECRET!)

export async function middleware(request: NextRequest) {
  const token = request.cookies.get('session')?.value

  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url))
  }

  try {
    // Full cryptographic verification on every request
    const { payload } = await jwtVerify(token, SECRET)

    // Pass the userId downstream via header
    const response = NextResponse.next()
    response.headers.set('x-user-id', payload.sub as string)
    return response
  } catch {
    return NextResponse.redirect(new URL('/login', request.url))
  }
}

export const config = {
  matcher: ['/dashboard/:path*', '/api/protected/:path*'],
}

The honest tradeoff: jwtVerify with jose does run in edge runtime. The cryptographic verification itself is fast. The problem shows up when the token has a short expiration and you also need to consult a revocation list, or when you want to verify granular permissions that live in a database. At that point you're in trouble, because doing a database fetch from middleware on every request is latency that adds up.

When it works well: long-lived tokens, no active revocation, where you only need to know if the token is structurally valid.

When it blows up: if your system revokes tokens (real logout, password change), this pattern won't reflect that until the token expires on its own.

Pattern 2 — Role-based redirects in middleware

This pattern looks simple but hides a race condition specific to the Next.js App Router.

// middleware.ts — role-based redirect pattern
export async function middleware(request: NextRequest) {
  const sessionCookie = request.cookies.get('session')?.value

  if (!sessionCookie) {
    return NextResponse.redirect(new URL('/login', request.url))
  }

  // Decoding without verifying — just to read the role from the payload
  // ⚠️ IMPORTANT: this is NOT a security verification
  const parts = sessionCookie.split('.')
  if (parts.length !== 3) {
    return NextResponse.redirect(new URL('/login', request.url))
  }

  const payload = JSON.parse(
    Buffer.from(parts[1], 'base64url').toString()
  )

  const { pathname } = request.nextUrl

  // Redirect based on role
  if (pathname.startsWith('/admin') && payload.role !== 'admin') {
    return NextResponse.redirect(new URL('/403', request.url))
  }

  return NextResponse.next()
}

The race condition problem: if you use NextResponse.redirect in middleware at the same time the client has a Server Component doing a fetch from layout.tsx, you can end up with two in-flight requests pointing to different destinations. The App Router has its own navigation mechanism and the middleware redirect interrupts the hydration cycle in ways that aren't always predictable.

The symptom: the user sees a content flash before the redirect, or gets stuck in a redirect loop on certain routes. Reproducible when the matcher covers routes with nested layouts that do their own fetching.

The fix: use NextResponse.rewrite instead of redirect for internal or API routes, and save redirect only for the "no session at all" case. For granular permissions within a valid session, delegate the decision to the Server Component or Route Handler — they have full database access.

Pattern 3 — API route protection only in middleware

This is the pattern I see recommended most often in tutorials, and it has the most expensive hidden cost.

The idea is to use the matcher to protect all /api/ routes from middleware and not validate anything inside the route handler itself.

// middleware.ts — API protection from middleware only
export const config = {
  matcher: ['/api/:path*'],
}

export async function middleware(request: NextRequest) {
  const token = request.headers.get('authorization')?.replace('Bearer ', '')

  if (!token) {
    return new NextResponse(
      JSON.stringify({ error: 'Unauthorized' }),
      { status: 401, headers: { 'content-type': 'application/json' } }
    )
  }

  // Verify token and let through
  try {
    await jwtVerify(token, SECRET)
    return NextResponse.next()
  } catch {
    return new NextResponse(
      JSON.stringify({ error: 'Invalid token' }),
      { status: 401, headers: { 'content-type': 'application/json' } }
    )
  }
}

The problem: this pattern assumes middleware is the only security layer. If you ever call a route handler directly and internally — Server Action, server-side fetch, another route handler — middleware doesn't intervene. That silent bypass is the security vector that costs the most to discover.

The real cost: middleware as the sole gatekeeper works if every single access path goes through the same door. In App Router, with Server Actions and server-side calls, that assumption doesn't always hold.

My rule: middleware protects the perimeter. Route handlers validate their own authorization. Both layers need to exist — it's not one or the other. If that sounds redundant, it's the kind of redundancy worth having.

Pattern 4 — Middleware composition

Next.js 16 doesn't have native nested middleware — there's one single middleware.ts file. To compose logic, the common pattern is manually chaining functions.

// middleware.ts — manual composition
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

// Each function returns NextResponse or null (to continue the chain)
type MiddlewareFn = (req: NextRequest) => NextResponse | null | Promise<NextResponse | null>

// Checks that a session exists
function withSession(req: NextRequest): NextResponse | null {
  const session = req.cookies.get('session')?.value
  if (!session) {
    return NextResponse.redirect(new URL('/login', req.url))
  }
  return null // continue
}

// Blocks admin routes for non-admins
function withAdminGuard(req: NextRequest): NextResponse | null {
  if (!req.nextUrl.pathname.startsWith('/admin')) return null

  const session = req.cookies.get('session')?.value
  if (!session) return null // withSession already handled this

  const parts = session.split('.')
  if (parts.length !== 3) return null

  const payload = JSON.parse(Buffer.from(parts[1], 'base64url').toString())

  if (payload.role !== 'admin') {
    return NextResponse.redirect(new URL('/403', req.url))
  }
  return null
}

// Composition function
function compose(...fns: MiddlewareFn[]) {
  return async (req: NextRequest): Promise<NextResponse> => {
    for (const fn of fns) {
      const result = await fn(req)
      if (result) return result // short-circuit on first result
    }
    return NextResponse.next()
  }
}

export const middleware = compose(withSession, withAdminGuard)

export const config = {
  matcher: ['/dashboard/:path*', '/admin/:path*'],
}

The tradeoff with this pattern: it's clean and scalable, but it has a maintenance cost. Each function in the pipeline decodes the token independently — if you have 4 guards that all read the same cookie, you're parsing the JWT 4 times per request.

The concrete optimization: parse the token once at the start and pass the payload as context through headers or an augmented request object. But Next.js has no native context mechanism between middleware functions, so the tradeoff is parsing multiple times vs. coupling the parsing to the start of the pipeline.

The gotchas nobody documents well

Buffer.from in edge runtime: in some edge deployments (Vercel Edge, Cloudflare Workers), Buffer isn't available globally. If you decode JWTs with Buffer.from(..., 'base64url'), your middleware can work locally and blow up in production. The portable alternative:

// Portable base64url decoding for edge runtime
function decodeJWTPayload(token: string): Record<string, unknown> {
  const base64 = token.split('.')[1]
    .replace(/-/g, '+')
    .replace(/_/g, '/')
  const json = atob(base64) // atob is available in Web APIs
  return JSON.parse(json)
}

The matcher and static routes: middleware runs on every request that matches, including static assets if the matcher isn't defined carefully. A poorly written matcher can run auth logic on .ico, .png, and font files. This isn't a bug — it's a silent CPU cost at the edge.

// recommended matcher: explicitly excludes assets
export const config = {
  matcher: [
    '/((?!_next/static|_next/image|favicon.ico|.*\\.png|.*\\.svg).*)',
  ],
}

Race condition with new session cookies: if middleware does a redirect at the same time the client is trying to write a new session cookie (e.g. right after login), the redirect can clear the cookie before it's persisted. Reproducible in login flows with an immediate redirect before the cookie is confirmed on the client.

The pattern I'd adopt in a new system

After analyzing all four, the one that best balances security, performance, and maintainability is a hybrid approach:

Middleware: verifies session existence (is there a token? does it look like a JWT?) and redirects if there's nothing there. No full cryptographic verification in middleware if active revocation is involved.
Server Components / Route Handlers: verify the full token with jose and check granular permissions if needed.
Restrictive matcher: app routes only, never static assets.

// middleware.ts — the pattern I'd use today
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

// Public paths that don't require a session
const PUBLIC_PATHS = ['/', '/login', '/register', '/api/auth']

function isPublicPath(pathname: string): boolean {
  return PUBLIC_PATHS.some(path => 
    pathname === path || pathname.startsWith(path + '/')
  )
}

function hasSessionShape(token: string): boolean {
  // Shape check only, not cryptographic
  // Real verification happens in the route handler or server component
  const parts = token.split('.')
  return parts.length === 3 && parts.every(p => p.length > 0)
}

export async function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl

  // Public paths: always let through
  if (isPublicPath(pathname)) {
    return NextResponse.next()
  }

  const sessionToken = request.cookies.get('session')?.value

  // No token: redirect to login
  if (!sessionToken || !hasSessionShape(sessionToken)) {
    const loginUrl = new URL('/login', request.url)
    loginUrl.searchParams.set('redirect', pathname)
    return NextResponse.redirect(loginUrl)
  }

  // Token with valid shape: let through
  // Cryptographic verification and permission checks happen downstream
  return NextResponse.next()
}

export const config = {
  matcher: [
    '/((?!_next/static|_next/image|favicon.ico|.*\\.(png|svg|jpg|ico)).*)',
  ],
}

This pattern is deliberately conservative: middleware does only what it can do well in edge runtime (checking the existence and shape of the token), and delegates real authorization to layers that have full access to the tools they need.

What you can't conclude without your own experiment

I'll be direct about the limits of this analysis:

Real latency per pattern: I don't have my own public production numbers comparing these 4 patterns in real scenarios. If you want to measure it, instrument with console.time in local middleware and compare with Edge Functions Logs in Vercel.
Behavior on Cloudflare Workers: Next.js 16 deployed on Workers can have edge runtime differences compared to Vercel Edge. The official docs cover the guaranteed subset; the rest depends on the provider.
Session cookie race condition across all browsers: the new session + immediate redirect race condition is reproducible under specific conditions. It's not universal — it depends on client timing and hosting provider.

What is backed by official documentation: the edge runtime limitations, unavailable modules, and matcher behavior are all described in Next.js Docs — Middleware and Next.js Docs — Edge Runtime.

FAQ — Common questions about Next.js 16 Middleware and authorization

Can I use jsonwebtoken in Next.js 16 middleware?
Not reliably. jsonwebtoken depends on Node.js's crypto module, which isn't available in edge runtime. The recommended alternative is jose, which uses Web Crypto API and works at the edge. Always check dependency compatibility against the official Edge Runtime APIs list.

Does Next.js 16 middleware replace validation in route handlers?
No, and thinking it does is a mistake. Middleware protects the external perimeter of the app. Route handlers can be invoked internally (Server Actions, server-side fetch) without going through middleware. If you only protect in middleware, you have a silent bypass on the internal surface.

When does it make sense to do full cryptographic verification in middleware?
When the token has no active revocation and the library is edge runtime compatible (jose). If you need to query a database to verify whether a token was revoked, that cost on every request scales badly. In that case, verify the shape in middleware and do the real check downstream.

Why can redirect loops appear in App Router with middleware?
The App Router has its own navigation system with prefetching. A NextResponse.redirect in middleware can interfere with prefetched requests, creating cycles if the redirect condition also gets evaluated at the destination. The practical rule: use redirect only for "no session", and rewrite or headers to communicate state to the rest of the system.

Does the matcher affect performance even if middleware does nothing?
Yes. Every request that matches executes the middleware, even if it immediately does NextResponse.next(). A too-broad matcher that includes static assets adds unnecessary overhead. The negative regex exclusion pattern ((?!_next/static|...)) is the correct way to limit scope.

Does it make sense to compose middlewares in Next.js 16 without native support?
It makes sense if the project grows in auth complexity (multiple roles, multiple protected paths). The cost is parsing the JWT in each pipeline function. The optimization is parsing once at the start and passing the result as an internal header. If the project is simple, a well-commented monolithic middleware is more maintainable than a chain of functions.

The middleware is not your primary authorization layer

My position is uncomfortable for anyone who learned Next.js from "protect your app in 10 minutes" tutorials: middleware is excellent for doing the cheapest check of all — does this look like a token? — and redirecting fast when there's nothing there. It's a presence guard, not an auditor.

Real authorization — permissions, roles, revocation, access to specific resources — belongs in layers that have full access to the tools you actually need: Server Components, Route Handlers, Server Actions. Those layers run on full Node.js, have database access, and can use any library.

The uncomfortable part is that this split requires you to write validation in two places. But the alternative — putting all the logic in middleware and trusting that edge runtime has everything you need — is the recipe for every problem I described above.

If you're working with TypeScript strict mode in the same project, the post on the tsconfig options that impact production the most has complementary context. And if you're thinking about App Router caching alongside auth, the Next.js App Router caching post covers the interactions you need to understand before mixing the two.

The concrete next step: open your own middleware.ts, look at what it's actually doing, and ask yourself whether each operation belongs in edge or in Node.js. The answer to that question defines how well the system scales when traffic grows.

Sources:

This article was originally published on juanchi.dev

Next.js 16 Middleware: patrones de autorización que escalan y los que generan race conditions

Juan Torchia — Thu, 04 Jun 2026 12:02:04 +0000

Next.js 16 Middleware: patrones de autorización que escalan y los que generan race conditions

El middleware de Next.js es básicamente como el portero de un boliche. No decide si sos bienvenido adentro — eso lo hace el staff interno. Pero sí decide si te deja pasar la puerta. Y si el portero empieza a revisar el historial completo de cada persona antes de abrir, la fila llega hasta la otra cuadra.

Ese es exactamente el problema con los patrones de autorización en Next.js 16 Middleware. La mayoría de los ejemplos que circulan online asumen que podés hacer validación completa de tokens en el edge. La realidad es más incómoda: el edge runtime tiene restricciones concretas, y varios patterns que funcionaban en v14 explotan en producción de maneras que no son obvias.

Mi tesis: el middleware de Next.js 16 es potente, pero su fortaleza está en verificar sesión, no en validar token completo. Cuando confundís los dos roles, generás race conditions o latencia que no entendés hasta que estás mirando logs a las 11 de la noche.

El problema real: edge runtime no es Node.js

Antes de ver cada patrón, hay un hecho que define todo lo que sigue: el middleware de Next.js corre en edge runtime, no en Node.js completo. Eso no es un detalle menor — es la razón por la que ciertos patterns fallan.

El edge runtime tiene acceso a APIs web estándar (Request, Response, Headers, crypto.subtle) pero no tiene acceso a:

fs — nada de leer archivos
módulos nativos de Node.js
librerías que dependan de buffers de Node o APIs de sistema

Lo que esto significa para auth es concreto: si tu librería de JWT usa jsonwebtoken con crypto de Node, no va a funcionar en middleware. Necesitás usar jose u otra librería compatible con Web Crypto API.

// ❌ Esto explota en edge runtime
import jwt from 'jsonwebtoken' // depende de crypto de Node

// ✅ Esto funciona en edge runtime
import { jwtVerify } from 'jose' // Web Crypto API compatible

La documentación oficial de Next.js Middleware lo menciona, pero entre tanto ejemplo de código uno tiende a saltear esa parte hasta que el error aparece en el deploy.

Los 4 patrones: análisis de tradeoffs

Patrón 1 — Validación de token completo en middleware

El más tentador y el más problemático.

La idea: agarrás el token de la cookie o el header Authorization, lo verificás criptográficamente en el middleware y decidís si el usuario pasa.

// middleware.ts
import { jwtVerify } from 'jose'
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

const SECRET = new TextEncoder().encode(process.env.JWT_SECRET!)

export async function middleware(request: NextRequest) {
  const token = request.cookies.get('session')?.value

  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url))
  }

  try {
    // Verificación criptográfica completa en cada request
    const { payload } = await jwtVerify(token, SECRET)

    // Pasamos el userId al header para usarlo downstream
    const response = NextResponse.next()
    response.headers.set('x-user-id', payload.sub as string)
    return response
  } catch {
    return NextResponse.redirect(new URL('/login', request.url))
  }
}

export const config = {
  matcher: ['/dashboard/:path*', '/api/protected/:path*'],
}

El tradeoff honesto: jwtVerify con jose sí corre en edge runtime. La verificación criptográfica en sí es rápida. El problema aparece cuando el token tiene expiración corta y necesitás también consultar una lista de revocación, o cuando querés verificar permisos granulares que están en base de datos. Ahí estás en problemas, porque hacer un fetch a base de datos desde middleware en cada request es latencia que se acumula.

Cuándo funciona bien: tokens de vida larga, sin revocación activa, donde solo necesitás saber si el token es válido estructuralmente.

Cuándo explota: si tu sistema revoca tokens (logout real, cambio de contraseña), este patrón no lo refleja hasta que el token expira.

Patrón 2 — Role-based redirects en middleware

Este patrón parece simple pero esconde una race condition específica de Next.js App Router.

// middleware.ts — patrón de redirects por rol
export async function middleware(request: NextRequest) {
  const sessionCookie = request.cookies.get('session')?.value

  if (!sessionCookie) {
    return NextResponse.redirect(new URL('/login', request.url))
  }

  // Decodificamos sin verificar — solo para leer el rol del payload
  // ⚠️ IMPORTANTE: esto NO es verificación de seguridad
  const parts = sessionCookie.split('.')
  if (parts.length !== 3) {
    return NextResponse.redirect(new URL('/login', request.url))
  }

  const payload = JSON.parse(
    Buffer.from(parts[1], 'base64url').toString()
  )

  const { pathname } = request.nextUrl

  // Redireccionamos según rol
  if (pathname.startsWith('/admin') && payload.role !== 'admin') {
    return NextResponse.redirect(new URL('/403', request.url))
  }

  return NextResponse.next()
}

El problema de race condition: si usás NextResponse.redirect en middleware al mismo tiempo que el cliente tiene un Server Component haciendo fetch desde layout.tsx, podés terminar con dos requests en vuelo apuntando a destinos distintos. El App Router tiene su propio mecanismo de navegación y el redirect del middleware interrumpe el ciclo de hidratación de manera que no siempre es predecible.

El síntoma: el usuario ve un flash de contenido antes del redirect, o queda en un loop de redirect en ciertas rutas. Reproducible cuando el matcher cubre rutas con layouts anidados que hacen fetch propio.

La corrección: usá NextResponse.rewrite en lugar de redirect para rutas de API o internas, y reservá redirect solo para el caso de "no hay sesión en absoluto". Para permisos granulares dentro de una sesión válida, delegá la decisión al Server Component o al Route Handler — que sí tienen acceso completo a base de datos.

Patrón 3 — API route protection solo en middleware

Este es el patrón que más veo recomendado en tutoriales y el que tiene el costo oculto más caro.

La idea es usar el matcher para proteger todas las rutas /api/ desde middleware y no validar nada dentro del route handler.

// middleware.ts — protección de API desde middleware únicamente
export const config = {
  matcher: ['/api/:path*'],
}

export async function middleware(request: NextRequest) {
  const token = request.headers.get('authorization')?.replace('Bearer ', '')

  if (!token) {
    return new NextResponse(
      JSON.stringify({ error: 'No autorizado' }),
      { status: 401, headers: { 'content-type': 'application/json' } }
    )
  }

  // Verificamos token y pasamos
  try {
    await jwtVerify(token, SECRET)
    return NextResponse.next()
  } catch {
    return new NextResponse(
      JSON.stringify({ error: 'Token inválido' }),
      { status: 401, headers: { 'content-type': 'application/json' } }
    )
  }
}

El problema: este patrón asume que middleware es la única capa de seguridad. Si alguna vez llamás directamente a un route handler internamente (Server Action, fetch server-side, otro route handler), el middleware no interviene. Ese bypass silencioso es el vector de seguridad que más cuesta descubrir.

El costo real: middleware como único guardián funciona si toda la superficie de acceso pasa por la misma puerta. En App Router, con Server Actions y llamadas server-side, esa suposición no siempre se cumple.

Mi criterio: middleware protege el perímetro. Los route handlers validan autorización propia. Las dos capas tienen que existir, no es una o la otra. Si esto te parece redundante, es redundancia que vale la pena.

Patrón 4 — Composición de middlewares

Next.js 16 no tiene middleware anidado nativo — hay un solo archivo middleware.ts. Para componer lógica, el patrón común es encadenar funciones manualmente.

// middleware.ts — composición manual
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

// Cada función devuelve NextResponse o null (para continuar la cadena)
type MiddlewareFn = (req: NextRequest) => NextResponse | null | Promise<NextResponse | null>

// Verifica que exista sesión
function withSession(req: NextRequest): NextResponse | null {
  const session = req.cookies.get('session')?.value
  if (!session) {
    return NextResponse.redirect(new URL('/login', req.url))
  }
  return null // continúa
}

// Bloquea rutas de admin para no-admins
function withAdminGuard(req: NextRequest): NextResponse | null {
  if (!req.nextUrl.pathname.startsWith('/admin')) return null

  const session = req.cookies.get('session')?.value
  if (!session) return null // withSession ya manejó esto

  const parts = session.split('.')
  if (parts.length !== 3) return null

  const payload = JSON.parse(Buffer.from(parts[1], 'base64url').toString())

  if (payload.role !== 'admin') {
    return NextResponse.redirect(new URL('/403', req.url))
  }
  return null
}

// Función de composición
function compose(...fns: MiddlewareFn[]) {
  return async (req: NextRequest): Promise<NextResponse> => {
    for (const fn of fns) {
      const result = await fn(req)
      if (result) return result // cortocircuito al primer resultado
    }
    return NextResponse.next()
  }
}

export const middleware = compose(withSession, withAdminGuard)

export const config = {
  matcher: ['/dashboard/:path*', '/admin/:path*'],
}

El tradeoff de este patrón: es limpio y escalable, pero tiene un costo de mantenimiento. Cada función del pipeline decodifica el token de manera independiente — si tenés 4 guards que todos leen el mismo cookie, estás parseando el JWT 4 veces por request.

La optimización concreta: parsear el token una sola vez al principio y pasar el payload como contexto a través de headers o de un objeto de request aumentado. Pero Next.js no tiene un mecanismo de contexto nativo entre funciones de middleware, así que el tradeoff es parsear múltiples veces vs. acoplar el parsing al inicio del pipeline.

Los gotchas que nadie documenta bien

Buffer.from en edge runtime: en algunos deployments de edge (Vercel Edge, Cloudflare Workers), Buffer no está disponible globalmente. Si decodificás JWT con Buffer.from(..., 'base64url'), tu middleware puede funcionar local y explotar en producción. La alternativa portable:

// Decodificación de base64url portable para edge runtime
function decodeJWTPayload(token: string): Record<string, unknown> {
  const base64 = token.split('.')[1]
    .replace(/-/g, '+')
    .replace(/_/g, '/')
  const json = atob(base64) // atob está disponible en Web APIs
  return JSON.parse(json)
}

El matcher y las rutas estáticas: el middleware corre en cada request que matchea, incluyendo assets estáticos si el matcher no está bien definido. Un matcher mal escrito puede ejecutar lógica de auth en archivos .ico, .png y fuentes. Esto no es un bug, es un costo silencioso de CPU en edge.

// matcher recomendado: excluye assets explícitamente
export const config = {
  matcher: [
    '/((?!_next/static|_next/image|favicon.ico|.*\\.png|.*\\.svg).*)',
  ],
}

Race condition con cookies de sesión nueva: si el middleware hace redirect y al mismo tiempo el cliente intenta escribir una cookie de sesión nueva (ej: después de login), el redirect puede limpiar la cookie antes de que se persista. Reproducible en flows de login con redirect inmediato sin esperar a que la cookie se confirme en el cliente.

El patrón que adoptaría en un sistema nuevo

Después de analizar los cuatro, el que mejor balancea seguridad, performance y mantenibilidad es una versión híbrida:

Middleware: verifica existencia de sesión (¿hay token? ¿tiene forma de JWT?) y redirige si no hay nada. Sin verificación criptográfica completa en el middleware si hay revocación activa.
Server Components / Route Handlers: verifican el token completo con jose y consultan permisos granulares si los necesitan.
Matcher restrictivo: solo rutas de app, nunca assets estáticos.

// middleware.ts — el pattern que adoptaría hoy
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

// Rutas públicas que no necesitan sesión
const PUBLIC_PATHS = ['/', '/login', '/register', '/api/auth']

function isPublicPath(pathname: string): boolean {
  return PUBLIC_PATHS.some(path => 
    pathname === path || pathname.startsWith(path + '/')
  )
}

function hasSessionShape(token: string): boolean {
  // Verificación de forma solamente, no criptográfica
  // La verificación real va en el route handler o server component
  const parts = token.split('.')
  return parts.length === 3 && parts.every(p => p.length > 0)
}

export async function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl

  // Rutas públicas: siempre pasan
  if (isPublicPath(pathname)) {
    return NextResponse.next()
  }

  const sessionToken = request.cookies.get('session')?.value

  // Sin token: redirigir a login
  if (!sessionToken || !hasSessionShape(sessionToken)) {
    const loginUrl = new URL('/login', request.url)
    loginUrl.searchParams.set('redirect', pathname)
    return NextResponse.redirect(loginUrl)
  }

  // Con token con forma válida: dejamos pasar
  // La verificación criptográfica y de permisos va downstream
  return NextResponse.next()
}

export const config = {
  matcher: [
    '/((?!_next/static|_next/image|favicon.ico|.*\\.(png|svg|jpg|ico)).*)',
  ],
}

Este patrón es deliberadamente conservador: el middleware hace solo lo que puede hacer bien en edge runtime (verificar existencia y forma del token), y delega la autorización real a capas que tienen acceso completo a las herramientas necesarias.

Lo que no podés concluir sin experimento propio

Seré directo sobre los límites de este análisis:

Latencia real por patrón: no tengo números públicos propios de producción para comparar los 4 patrones en escenarios reales. Si querés medirlo, instrumentá con console.time en middleware local y compará con Edge Functions Logs en Vercel.
Comportamiento en Cloudflare Workers: Next.js 16 deployado en Workers puede tener diferencias de edge runtime respecto a Vercel Edge. La documentación oficial cubre el subset garantizado; el resto depende del provider.
Race condition de cookies en todos los browsers: la race condition de sesión nueva + redirect inmediato es reproducible en condiciones específicas. No es universal — depende del timing del cliente y del provider de hosting.

Lo que sí está respaldado por documentación oficial: las limitaciones del edge runtime, los módulos no disponibles y el comportamiento del matcher son descritos en Next.js Docs — Middleware y Next.js Docs — Edge Runtime.

FAQ — Preguntas frecuentes sobre Next.js 16 Middleware y autorización

¿Puedo usar jsonwebtoken en el middleware de Next.js 16?
No de manera confiable. jsonwebtoken depende del módulo crypto de Node.js, que no está disponible en edge runtime. La alternativa recomendada es jose, que usa Web Crypto API y funciona en edge. Verificá siempre la compatibilidad de dependencias con el listado oficial de Edge Runtime APIs.

¿El middleware de Next.js 16 reemplaza la validación en los route handlers?
No, y es un error pensarlo así. El middleware protege el perímetro externo de la app. Los route handlers pueden ser invocados internamente (Server Actions, fetch server-side) sin pasar por middleware. Si solo protegés en middleware, tenés un bypass silencioso en el surface interno.

¿Cuándo tiene sentido hacer verificación criptográfica completa en middleware?
Cuando el token no tiene revocación activa y la librería es compatible con edge runtime (jose). Si necesitás consultar base de datos para verificar si el token fue revocado, ese costo en cada request escala mal. En ese caso, verificá la forma en middleware y hacé la consulta real downstream.

¿Por qué pueden aparecer loops de redirect en App Router con middleware?
El App Router tiene su propio sistema de navegación con prefetching. Un NextResponse.redirect en middleware puede interferir con requests prefetcheados, generando ciclos si la condición de redirect se evalúa también en el destino. La regla práctica: usá redirect solo para "no hay sesión", y rewrite o headers para comunicar estado al resto del sistema.

¿El matcher afecta la performance aunque el middleware no haga nada?
Sí. Cada request que matchea ejecuta el middleware, aunque sea para hacer NextResponse.next() inmediatamente. Un matcher demasiado amplio que incluye assets estáticos suma overhead innecesario. El patrón de exclusión con regex negativo ((?!_next/static|...)) es la forma correcta de limitar el scope.

¿Tiene sentido componer middlewares en Next.js 16 si no hay soporte nativo?
Tiene sentido si el proyecto crece en complejidad de auth (múltiples roles, múltiples paths protegidos). El costo es parsear el JWT en cada función del pipeline. La optimización es parsear una sola vez al inicio y pasar el resultado como header interno. Si el proyecto es simple, un middleware monolítico bien comentado es más mantenible que una cadena de funciones.

Conclusión: el middleware no es tu capa de autorización principal

Mi postura es incómoda para quienes aprendieron Next.js con tutoriales de "protegé tu app en 10 minutos": el middleware es excelente para hacer el check más barato de todos — ¿hay algo que parece un token? — y redirigir rápido cuando no hay nada. Es un guardia de presencia, no un auditor.

La autorización real — permisos, roles, revocación, acceso a recursos específicos — pertenece a capas que tienen acceso completo a las herramientas que necesitás: Server Components, Route Handlers, Server Actions. Esas capas corren en Node.js completo, tienen acceso a base de datos y pueden usar cualquier librería.

Lo incómodo es que este split requiere que escribas validación en dos lugares. Pero la alternativa — poner toda la lógica en middleware y confiar en que el edge runtime tiene todo lo que necesitás — es la receta para los problemas que describí arriba.

Si trabajás con TypeScript strict en el mismo proyecto, el post sobre las opciones de tsconfig que más impactan en producción tiene contexto complementario. Y si estás pensando en caching de App Router junto con auth, el post de Next.js App Router caching tiene las interacciones que hay que entender antes de mezclar las dos cosas.

El próximo paso concreto: abrí el middleware.ts propio, fijate qué está haciendo realmente y preguntate si cada operación pertenece a edge o a Node.js. La respuesta a esa pregunta define qué tan bien escala el sistema cuando el tráfico crece.

Fuentes:

Este artículo fue publicado originalmente en juanchi.dev

Prisma 5 Prisma 6: The Breaking Changes I Hit in My Real Schema and How I Fixed Them Without Breaking Production

Juan Torchia — Wed, 03 Jun 2026 12:01:43 +0000

Prisma 5 → Prisma 6: The Breaking Changes I Hit in My Real Schema and How I Fixed Them Without Breaking Production

The correct approach to migrating from Prisma 5 to Prisma 6 without breaking anything is don't run the upgrade on a Friday. I know that sounds obvious. But that's not actually the point — the real point is this: Prisma 6 has changes that TypeScript's compiler is not going to yell at you about. They'll pass through silently, and you'll find out at runtime — or worse, from a query result that looks correct but isn't.

My thesis: Prisma 6 is a genuine improvement in ergonomics and performance, but there are three behavior changes that require manual attention before you upgrade. They're not bugs — they're deliberate decisions by the Prisma team that change how relational queries, the generated client, and transactions behave. If you don't know about them upfront, they'll find you.

What follows is my analysis of those three changes, with representative code and the checklist I built so I don't have to repeat the experience.

Why Prisma 6 Matters (and What the Official Announcement Actually Says)

The official announcement — "What's new in Prisma 6" — has three main pillars:

Better performance — rewritten internals, more efficient query engine.
More flexibility — improved support for multiple providers and client configuration.
Type-safe SQL — the new prisma.$queryRawTyped API with real type inference.

All of that is real and welcome. What the announcement doesn't emphasize enough — and what costs you time when you upgrade without reading the full migration guide — are the behaviors that changed silently.

I'm going to cover the three that hit hardest in a Next.js 16 + Server Actions + PostgreSQL stack.

Change 1: `selectRelationCount` Is No Longer Opt-In — How You Count Relations Changed

In Prisma 5, if you wanted to count relations (say, how many posts a user has) inside a select, you had to enable the selectRelationCount preview feature in the schema:

// schema.prisma — Prisma 5
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["selectRelationCount"]
}

In Prisma 6, selectRelationCount went GA and the preview flag was removed. If you leave it in the schema, the Prisma CLI throws a warning — or an outright error depending on the exact version. The functionality still works, but the API changed subtly in how it integrates with include vs select.

// ✅ Prisma 5 — worked with the preview feature active
const users = await prisma.user.findMany({
  select: {
    id: true,
    name: true,
    _count: {
      select: { posts: true }
    }
  }
})

// ✅ Prisma 6 — same syntax, but without the flag in the schema
// If the flag is still there, the CLI emits a warning on generate
const users = await prisma.user.findMany({
  select: {
    id: true,
    name: true,
    _count: {
      select: { posts: true }
    }
  }
})

Concrete action: grep all previewFeatures in your schema and verify which ones went GA in v6. The official guide lists them. Remove them before running prisma generate.

Change 2: The Behavior of `undefined` in Relational Queries Changed

This is the one that hurts the most because there's no compile-time error. In Prisma 5, passing undefined as a value in a where was ignored — the filter simply wasn't applied. In Prisma 6, that behavior was standardized more strictly: in some cases undefined is still ignored, but in others — especially inside nested selects with optional relations — the behavior differs depending on whether the field is nullable in the schema or not.

// ⚠️ Dangerous pattern in the Prisma 5 → 6 transition
async function getPosts(categoryFilter?: string) {
  return await prisma.post.findMany({
    where: {
      // In Prisma 5: if categoryFilter is undefined, this where was ignored
      // In Prisma 6: behavior depends on the field's type in the schema
      // If 'category' is an optional field (String?), it may behave differently
      category: categoryFilter,
    },
    include: {
      author: true
    }
  })
}

The fix is explicit and more defensive:

// ✅ Safe pattern for both Prisma 5 and 6
async function getPosts(categoryFilter?: string) {
  return await prisma.post.findMany({
    where: {
      // Build the where conditionally — don't depend on undefined's behavior
      ...(categoryFilter !== undefined && { category: categoryFilter }),
    },
    include: {
      author: true
    }
  })
}

The uncomfortable part about this change: the TypeScript types in the generated client don't change. String | undefined is still a valid type in the where. The compiler tells you nothing. You have to find it manually or with integration tests.

My take here: building where objects conditionally isn't a workaround — it's the correct practice in any version of Prisma. If your codebase has a lot of places where you pass optional variables directly into where, this is the moment to clean them up.

Change 3: The Generated Client Was Reorganized and Direct Type Imports Can Break

Prisma 6 reorganized the structure of the generated client. If anywhere in your codebase you're importing types directly from the .prisma/client folder or from internal package paths (something that shouldn't be done but shows up in old tutorials), those imports can break silently or with cryptic errors.

// ❌ Fragile pattern — importing from internal paths of the generated client
// This might have worked in Prisma 5 but it's a private API, not public
import { Prisma } from '@prisma/client/edge'

// ✅ Always import from the public entry point
import { Prisma, PrismaClient } from '@prisma/client'

The most common case in Next.js 16 with Server Actions: using the edge client (@prisma/client/edge) for middleware or routes running in the Edge Runtime. In Prisma 6, the edge client configuration was unified and the way you instantiate it changed. The official docs have the updated details, but the error you'll see if you don't update is generic — something like "cannot find module" or "type is not assignable" that doesn't point directly at the problem.

// ✅ Prisma 6 with Next.js 16 — single client instance
// lib/prisma.ts
import { PrismaClient } from '@prisma/client'

const globalForPrisma = global as unknown as { prisma: PrismaClient }

export const prisma =
  globalForPrisma.prisma ??
  new PrismaClient({
    // log only in development — don't expose query logs in production
    log: process.env.NODE_ENV === 'development' ? ['query', 'error'] : ['error'],
  })

if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma

This pattern didn't change between v5 and v6, but if you had it misconfigured (multiple instances, broken singleton), the upgrade is the moment to fix it.

Common Migration Mistakes — The Gotchas That Keep Showing Up

Gotcha 1: running prisma db push without reading the full output.

Prisma 6 can generate slightly different migrations for the same schema if there are fields with types that changed internally (like some DateTime types with precision). Review the migration diff before applying it.

Gotcha 2: assuming prisma migrate dev and prisma migrate deploy behave the same way.

migrate dev can do additional things (like resetting the DB on conflicts). In any environment that resembles production, always use migrate deploy and check state with prisma migrate status first.

# Check migration state before upgrading
npx prisma migrate status

# Generate the client after updating the version
npx prisma generate

# Review schema differences without applying anything
npx prisma migrate diff \
  --from-schema-datasource prisma/schema.prisma \
  --to-schema-datamodel prisma/schema.prisma \
  --script

Gotcha 3: not updating devDependencies alongside @prisma/client.

prisma (the CLI) and @prisma/client need to be on the same major version. If you update one and not the other, you'll get client generation errors that are hard to diagnose.

# Always update both at the same time
npm install prisma@6 @prisma/client@6

# Or with pnpm
pnpm add prisma@6 @prisma/client@6

Gotcha 4: transaction behavior with $transaction and timeouts.

Prisma 6 adjusted the default timeouts for interactive transactions. If you have transactions running slow operations, the default timeout may be different. Verify and set it explicitly:

// ✅ Explicit timeout — don't depend on the default
await prisma.$transaction(
  async (tx) => {
    // transaction operations
  },
  {
    maxWait: 5000,  // ms — max time waiting to acquire the transaction
    timeout: 10000  // ms — max execution time
  }
)

Prisma 5 → 6 Migration Checklist

This is the order I follow to upgrade without surprises. It's not the only path, but it covers the edge cases that come up most often:

Before the upgrade:

[ ] Review all previewFeatures in the schema — verify which ones went GA in v6 and remove the corresponding flags
[ ] Audit all where clauses that receive optional variables — replace the field: variable | undefined pattern with explicit conditional construction
[ ] Search for imports from internal @prisma/client paths — centralize on the public entry point
[ ] Verify explicit timeouts on all interactive $transaction calls
[ ] Run prisma migrate status and make sure there are no pending migrations before upgrading

During the upgrade:

[ ] Update prisma and @prisma/client to the same major version simultaneously
[ ] Run prisma generate and review the full output — not just that it finishes without error
[ ] Run the integration test suite (if you have one) pointing at a staging DB, not production
[ ] If you use Next.js 16 with Edge Runtime, verify the edge client configuration per the Prisma 6 docs

After the upgrade:

[ ] Monitor query logs in the first few hours — look for slower queries or unexpected results in optional relations
[ ] Verify that the PrismaClient singleton is still working correctly in Next.js's lifecycle (hot reload in dev, single instance in prod)

FAQ — Prisma 6 Migration Breaking Changes

Is Prisma 6 compatible with Prisma 5 without changes?

Not completely. There are breaking changes documented in the official migration guide. Most are manageable, but they require manual review — especially in schemas with previewFeatures, relational queries with optional values, and edge client usage. This isn't a patch upgrade; take it seriously.

Does the Prisma schema (schema.prisma) change between v5 and v6?

The schema format didn't change dramatically, but there are previewFeatures flags that need to be removed because they went GA. If you leave them in, the CLI may emit warnings or errors depending on the exact version. Check the full list in the official announcement.

Will my queries with include and optional relations work the same?

Probably yes for simple cases. The risk is in queries that pass undefined conditionally to optional fields in where. If you build filters explicitly (without depending on undefined's behavior), the risk is low.

Does Prisma 6 work with Next.js 16 App Router and Server Actions?

Yes. The Next.js 16 + Server Actions + Prisma 6 + PostgreSQL stack works well. What needs attention is the client instance (global singleton) and the Edge Runtime configuration if you use it. The Prisma patterns with Server Actions I covered in the previous post on Server Actions and Prisma are still valid — just verify the client entry point.

Can I upgrade directly in production?

My recommendation is no. The safest flow is: upgrade branch → staging with a DB similar to production → integration test suite → deploy during low-traffic hours. The upgrade itself isn't risky if you follow the checklist, but the prior validation is what saves you from surprises.

Does $queryRawTyped replace $queryRaw?

It doesn't replace it, it complements it. $queryRawTyped is the new API for type-safe SQL with type inference — a genuine improvement for complex SQL queries that the ORM can't express well. $queryRaw still works. If you want to explore the new API, the official announcement has the examples; if you already use query logging with PostgreSQL to debug heavy queries, $queryRawTyped will be a natural ally.

The Upgrade Is Worth It, But You Have to Earn It

Prisma 6 is a real step forward — better performance, faster client generation, and type-safe SQL are concrete improvements that you feel in projects with complex schemas. I'm not questioning that.

What I am saying is that there are three behaviors that won't scream at you in the compiler: cleaning up previewFeatures, handling undefined in conditional where objects, and imports from the generated client. Ignore them, and you find out at runtime.

The truly uncomfortable part is that none of the three are Prisma bugs — they're reasonable decisions by the team that prioritize correct behavior over silent compatibility. But if you don't read the full migration guide before running npm install prisma@6, you're the one paying the cost.

My practical recommendation: before upgrading, run a grep through the codebase for previewFeatures, for field: variable patterns in where objects, and for imports from internal @prisma/client paths. If all three come back clean, the upgrade will be smooth. If something shows up, you know before you start.

If you're on the path of query hardening and logging, the post on Prisma query logging and PostgreSQL has useful context for the monitoring side post-upgrade. And if the project uses TypeScript strict mode, the strictNullChecks and noUncheckedIndexedAccess options will make exactly the undefined patterns I described here more visible.

Original source:

Prisma — What's new in Prisma 6: https://www.prisma.io/blog/prisma-6-better-performance-more-flexibility-and-type-safe-sql

This article was originally published on juanchi.dev

Prisma 5 Prisma 6: los breaking changes que encontré en mi schema real y cómo los resolví sin romper producción

Juan Torchia — Wed, 03 Jun 2026 12:01:38 +0000

Prisma 5 → Prisma 6: los breaking changes que encontré en mi schema real y cómo los resolví sin romper producción

La solución correcta para migrar de Prisma 5 a Prisma 6 sin romper nada es no correr el upgrade el viernes. Sé que suena obvio. Pero el punto real es otro: Prisma 6 tiene cambios que el compilador de TypeScript no te va a gritar. Van a pasar silenciosamente, y vas a enterarte en runtime — o peor, en un resultado de query que parece correcto pero no lo es.

Mi tesis es esta: Prisma 6 es una mejora genuina en ergonomía y performance, pero hay tres cambios de comportamiento que requieren atención manual antes de hacer el upgrade. No son bugs — son decisiones deliberadas del equipo de Prisma que cambian cómo se comportan las queries relacionales, el cliente generado y las transacciones. Si no los conocés de antemano, te van a encontrar ellos a vos.

Lo que sigue es el análisis de esos tres cambios, con código representativo y el checklist que construí para no repetirlo.

Por qué Prisma 6 importa (y qué dice el anuncio oficial)

El anuncio oficial de Prisma — "What's new in Prisma 6" — tiene tres ejes centrales:

Mejor performance — internals reescritos, query engine más eficiente.
Más flexibilidad — soporte mejorado para múltiples providers y configuración del cliente.
SQL type-safe — la nueva API prisma.$queryRawTyped con inferencia real.

Todo eso es real y bienvenido. Lo que el anuncio no dice con énfasis suficiente — y lo que te cuesta tiempo cuando hacés el upgrade sin leer la guía de migración completa — son los comportamientos que cambiaron silenciosamente.

Voy a cubrir los tres que más impactan en un stack Next.js 16 + Server Actions + PostgreSQL.

Cambio 1: `selectRelationCount` ya no es opt-in — cambió la forma de contar relaciones

En Prisma 5, si querías contar relaciones (por ejemplo, cuántos posts tiene un usuario) dentro de un select, tenías que habilitar el preview feature selectRelationCount en el schema:

// schema.prisma — Prisma 5
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["selectRelationCount"]
}

En Prisma 6, selectRelationCount pasó a ser GA y la flag de preview fue removida. Si la dejás en el schema, Prisma CLI te lanza un warning — o directamente un error dependiendo de la versión puntual. La funcionalidad sigue andando, pero el API cambió sutilmente en cómo se integra con include vs select.

// ✅ Prisma 5 — funcionaba con la preview feature activa
const usuarios = await prisma.usuario.findMany({
  select: {
    id: true,
    nombre: true,
    _count: {
      select: { posts: true }
    }
  }
})

// ✅ Prisma 6 — misma sintaxis, pero sin la flag en el schema
// Si la flag sigue presente, el CLI emite warning en generate
const usuarios = await prisma.usuario.findMany({
  select: {
    id: true,
    nombre: true,
    _count: {
      select: { posts: true }
    }
  }
})

Acción concreta: buscá todas las previewFeatures en el schema y verificá cuáles pasaron a GA en v6. La guía oficial lista cuáles ya no son preview. Removalas antes de correr prisma generate.

Cambio 2: el comportamiento de `undefined` en queries relacionales cambió

Este es el que más duele porque no hay error en tiempo de compilación. En Prisma 5, pasar undefined como valor en un where era ignorado — el filtro simplemente no se aplicaba. En Prisma 6, ese comportamiento fue estandarizado de forma más estricta: en algunos casos undefined sigue siendo ignorado, pero en otros — especialmente dentro de select anidados con relaciones opcionales — el comportamiento difiere según si el campo es nullable o no en el schema.

// ⚠️ Patrón peligroso en la transición Prisma 5 → 6
async function obtenerPosts(filtroCategoria?: string) {
  return await prisma.post.findMany({
    where: {
      // En Prisma 5: si filtroCategoria es undefined, este where era ignorado
      // En Prisma 6: el comportamiento depende del tipo del campo en el schema
      // Si 'categoria' es un campo opcional (String?), puede comportarse diferente
      categoria: filtroCategoria,
    },
    include: {
      autor: true
    }
  })
}

El fix es explícito y más defensivo:

// ✅ Patrón seguro para Prisma 5 y 6
async function obtenerPosts(filtroCategoria?: string) {
  return await prisma.post.findMany({
    where: {
      // Construí el where condicionalmente — no dependas del comportamiento de undefined
      ...(filtroCategoria !== undefined && { categoria: filtroCategoria }),
    },
    include: {
      autor: true
    }
  })
}

Lo incómodo de este cambio: el TypeScript types del cliente generado no cambian. String | undefined sigue siendo válido como tipo en el where. El compilador no te avisa nada. Tenés que buscarlo a mano o con tests de integración.

Mi punto acá: construir los objetos where condicionalmente no es un workaround — es la práctica correcta en cualquier versión de Prisma. Si tu codebase tiene muchos lugares donde pasás variables opcionales directo al where, este es el momento de limpiarlos.

Cambio 3: el cliente generado cambió y los imports directos de tipos pueden romperse

Prisma 6 reorganizó la estructura del cliente generado. Si en algún lugar de la codebase importás tipos directamente desde la carpeta .prisma/client o desde rutas internas del paquete (algo que no debería hacerse pero que aparece en tutoriales viejos), esos imports pueden romperse silenciosamente o con errores crípticos.

// ❌ Patrón frágil — importar desde rutas internas del cliente generado
// Esto podía funcionar en Prisma 5 pero es una API privada, no pública
import { Prisma } from '@prisma/client/edge'

// ✅ Importá desde el punto de entrada público siempre
import { Prisma, PrismaClient } from '@prisma/client'

El caso más frecuente en Next.js 16 con Server Actions: usar el cliente de edge (@prisma/client/edge) para middleware o rutas que corren en el Edge Runtime. En Prisma 6, la configuración del cliente de edge fue unificada y la forma de instanciarlo cambió. La documentación oficial tiene el detalle actualizado, pero el error que vas a ver si no lo actualizás es genérico — algo del estilo "cannot find module" o "type is not assignable" que no señala directamente el problema.

// ✅ Prisma 6 con Next.js 16 — instancia única del cliente
// lib/prisma.ts
import { PrismaClient } from '@prisma/client'

const globalForPrisma = global as unknown as { prisma: PrismaClient }

export const prisma =
  globalForPrisma.prisma ??
  new PrismaClient({
    // log solo en desarrollo — no expongas query logs en producción
    log: process.env.NODE_ENV === 'development' ? ['query', 'error'] : ['error'],
  })

if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma

Este patrón no cambió entre v5 y v6, pero si lo tenías mal configurado (instancias múltiples, singleton roto), el upgrade es el momento de corregirlo.

Errores comunes en la migración — los gotchas que más aparecen

Gotcha 1: correr prisma db push sin leer el output completo.

Prisma 6 puede generar migraciones ligeramente diferentes para el mismo schema si hay campos con tipos que cambiaron internamente (como algunos tipos de DateTime con precisión). Revisá el diff de migración antes de aplicarlo.

Gotcha 2: asumir que prisma migrate dev y prisma migrate deploy se comportan igual.

migrate dev puede hacer cosas adicionales (como resetear la DB en conflictos). En un entorno que se parece a producción, usá siempre migrate deploy y revisá el estado con prisma migrate status antes.

# Verificá el estado de migraciones antes del upgrade
npx prisma migrate status

# Generá el cliente después de actualizar la versión
npx prisma generate

# Revisá las diferencias de schema sin aplicar nada
npx prisma migrate diff \
  --from-schema-datasource prisma/schema.prisma \
  --to-schema-datamodel prisma/schema.prisma \
  --script

Gotcha 3: no actualizar las devDependencies junto con @prisma/client.

prisma (el CLI) y @prisma/client tienen que estar en la misma versión mayor. Si actualizás uno y no el otro, vas a tener errores de generación de cliente que son difíciles de diagnosticar.

# Actualizá ambos juntos siempre
npm install prisma@6 @prisma/client@6

# O con pnpm
pnpm add prisma@6 @prisma/client@6

Gotcha 4: el comportamiento de transacciones con $transaction y timeouts.

Prisma 6 ajustó los defaults de timeout en transacciones interactivas. Si tenés transacciones que corren operaciones lentas, el timeout default puede ser diferente. Verificá y setealo explícitamente:

// ✅ Timeout explícito — no dependas del default
await prisma.$transaction(
  async (tx) => {
    // operaciones de la transacción
  },
  {
    maxWait: 5000,  // ms — máximo tiempo esperando adquirir la transacción
    timeout: 10000  // ms — máximo tiempo de ejecución
  }
)

Checklist de migración Prisma 5 → 6

Este es el orden que sigo para hacer un upgrade sin sustos. No es el único camino, pero cubre los edge cases que más aparecen:

Antes del upgrade:

[ ] Revisá todas las previewFeatures en el schema — verificá cuáles pasaron a GA en v6 y eliminá las flags correspondientes
[ ] Auditá todos los where que reciben variables opcionales — reemplazá el patrón campo: variable | undefined por construcción condicional explícita
[ ] Buscá imports desde rutas internas de @prisma/client — centralizá en el punto de entrada público
[ ] Verificá los timeouts explícitos en todas las $transaction interactivas
[ ] Corré prisma migrate status y asegurate de que no haya migraciones pendientes antes del upgrade

Durante el upgrade:

[ ] Actualizá prisma y @prisma/client a la misma versión mayor simultáneamente
[ ] Corré prisma generate y revisá el output completo — no solo que termine sin error
[ ] Corré el test suite de integración (si tenés) apuntando a una DB de staging, no producción
[ ] Si usás Next.js 16 con Edge Runtime, verificá la configuración del cliente de edge según la doc de Prisma 6

Después del upgrade:

[ ] Monitoreá los query logs en las primeras horas — buscá queries más lentas o resultados inesperados en relaciones opcionales
[ ] Verificá que el singleton de PrismaClient siga funcionando correctamente en el ciclo de vida de Next.js (hot reload en dev, instancia única en prod)

FAQ — Prisma 6 migration breaking changes

¿Prisma 6 es compatible con Prisma 5 sin cambios?

No completamente. Hay breaking changes documentados en la guía oficial. La mayoría son manejables, pero requieren revisión manual — especialmente en schemas con previewFeatures, queries relacionales con valores opcionales y uso del cliente de edge. No es un upgrade de patch; tomalo en serio.

¿El schema de Prisma (schema.prisma) cambia entre v5 y v6?

El formato del schema no cambió drásticamente, pero sí hay flags de previewFeatures que deben removerse porque pasaron a GA. Si las dejás, el CLI puede emitir warnings o errores dependiendo de la versión puntual. Revisá la lista completa en el anuncio oficial.

¿Mis queries con include y relaciones opcionales van a funcionar igual?

Probablemente sí para los casos simples. El riesgo está en queries que pasan undefined condicionalmente a campos opcionales del where. Si construís los filtros de forma explícita (sin depender del comportamiento de undefined), el riesgo es bajo.

¿Prisma 6 funciona con Next.js 16 App Router y Server Actions?

Sí. El stack Next.js 16 + Server Actions + Prisma 6 + PostgreSQL funciona bien. Lo que requiere atención es la instancia del cliente (singleton global) y la configuración del Edge Runtime si la usás. Los patterns de Prisma con Server Actions que cubrí en el post anterior sobre Server Actions y Prisma siguen siendo válidos — solo verificá el punto de entrada del cliente.

¿Puedo hacer el upgrade en producción directamente?

Mi recomendación es no. El flujo más seguro es: rama de upgrade → staging con DB similar a producción → test suite de integración → deploy en horario de bajo tráfico. El upgrade en sí no es riesgoso si seguís el checklist, pero la validación previa es lo que te salva de sorpresas.

¿$queryRawTyped reemplaza a $queryRaw?

No lo reemplaza, lo complementa. $queryRawTyped es la nueva API para SQL type-safe con inferencia de tipos — es una mejora genuina para queries SQL complejas que el ORM no puede expresar bien. $queryRaw sigue funcionando. Si querés explorar la nueva API, el anuncio oficial tiene los ejemplos; si ya usás query logging con PostgreSQL para debuguear queries pesadas, $queryRawTyped va a ser tu aliado natural.

Conclusión: vale el upgrade, pero hay que ganárselo

Prisma 6 es un paso adelante real — mejor performance, client generation más rápida y SQL type-safe son mejoras concretas que se sienten en proyectos con schemas complejos. No lo estoy cuestionando.

Lo que sí estoy diciendo es que hay tres comportamientos que no gritan en el compilador: la limpieza de previewFeatures, el manejo de undefined en where condicionales y los imports del cliente generado. Si los ignorás, te enterás en runtime.

Lo incómodo de verdad es que ninguno de los tres es un bug de Prisma — son decisiones razonables del equipo que priorizan comportamiento correcto sobre compatibilidad silenciosa. Pero si no leés la guía de migración completa antes de correr npm install prisma@6, el costo lo pagás vos.

Mi recomendación práctica: antes de hacer el upgrade, corré un grep en la codebase por previewFeatures, por patrones campo: variable en objetos where, y por imports desde rutas internas de @prisma/client. Si los tres resultados están limpios, el upgrade va a ser tranquilo. Si aparece algo, lo sabés antes de empezar.

Si estás en el camino de hardening de queries y logging, el post sobre Prisma query logging y PostgreSQL tiene contexto útil para el lado del monitoreo post-upgrade. Y si el proyecto usa TypeScript strict mode, las opciones strictNullChecks y noUncheckedIndexedAccess van a hacer más visibles exactamente los patrones de undefined que describí acá.

Fuente original:

Prisma — What's new in Prisma 6: https://www.prisma.io/blog/prisma-6-better-performance-more-flexibility-and-type-safe-sql

Este artículo fue publicado originalmente en juanchi.dev

tsgo: what changes in the TypeScript compiler rewritten in Go and what it means for real projects

Juan Torchia — Tue, 02 Jun 2026 14:31:59 +0000

tsgo: what changes in the TypeScript compiler rewritten in Go and what it means for real projects

I made the mistake of dismissing tsgo as hype before actually reading it. I saw the "10x faster" headline and mentally filed it next to JavaScript framework benchmarks — real numbers in a context that has nothing to do with my work. It only took opening the official repository and the TypeScript team's announcement to understand that this time the story is different. And that it's worth understanding exactly what changed, what hasn't yet, and when it actually makes sense to explore the migration.

My thesis is simple: tsgo is a legitimate technical bet with public evidence behind it, but the beta has documented limitations that most enthusiastic posts quietly skip. The criterion for migrating today isn't whether the number looks attractive — it's whether your CI spends more than 5 minutes on type-checking. If you don't hit that threshold, wait for stable and sleep easy.

tsgo typescript compiler go: what it is and where it came from

The official project lives at github.com/microsoft/typescript-go. This isn't a fork or a community experiment — it's the TypeScript team itself porting the compiler to native Go, with the declared goal of leveraging real parallelism and eliminating V8 overhead.

The official announcement on the TypeScript Blog is clear about the reasoning: JavaScript has a ceiling on compilation speed because it runs on a general-purpose runtime. Go lets you compile to a native binary, manage goroutines for genuine parallelism, and avoid V8's garbage collector pressure. The result according to the team's own measurements: compilations that take tens of seconds with classic TypeScript drop to a few seconds or less.

The important thing is that tsgo does not change the type system. TypeScript's semantics — the same errors, the same inferences, the same strict behavior — stay identical. What changes is the speed at which you get to those results.

# Experimental installation per the official repo
# Not on stable npm yet — follow the repo's README
git clone https://github.com/microsoft/typescript-go
cd typescript-go

# Build the binary (requires Go installed)
go build ./cmd/tsgo

# Run type-check on a project
./tsgo --project path/to/tsconfig.json

What limitations the beta has today

This is where most posts fall short. The official repository's roadmap explicitly documents what isn't ready in the beta:

Language Service (LSP) incomplete. Editor integration — VS Code, Neovim, any LSP client — is in progress but doesn't have parity with tsc. That means you can't replace the language server that gives you hover types, go-to-definition, and autocomplete today. The CLI type-check is the most mature piece.

Build mode and project references. Support for tsc --build with composite: true and references between packages in a monorepo is partially implemented. If you're using pnpm workspaces with multiple linked tsconfig.json files, you'll hit edge cases.

TypeScript plugins. The plugins in tsconfig.json that many frameworks use internally — Next.js ships its own — don't have guaranteed support yet.

Code transformations. tsgo in beta is a type-checker, not a full transpiler. It doesn't replace tsc when you need to emit .js from .ts with transformations. That's still territory for the original compiler or tools like esbuild/swc.

// Typical tsconfig.json in a Next.js project with strict mode
// What tsgo can type-check today (CLI)
{
  "compilerOptions": {
    "strict": true,
    "noEmit": true,         // ← "type-check only, no emit" mode — the most mature case in tsgo
    "target": "ESNext",
    "moduleResolution": "Bundler",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}
// What's NOT ready: plugins like Next.js's own, complex composite + references

If you have strict: true enabled — and if you're not sure why you should, I have a post on the tsconfig options that actually matter in production — tsgo respects exactly that semantics. The port doesn't relax or change the checks.

The common mistakes when evaluating tsgo

Mistake 1: comparing the number without project context. The "10x" comes from benchmarks on large codebases. On a 50-file project where tsc --noEmit takes 8 seconds, the jump will be noticeable but not dramatic. On a monorepo with 500+ files where type-checking in CI takes 4–6 minutes, the difference concretely changes your pipeline.

Mistake 2: assuming it replaces the entire toolchain. tsgo in beta is a type-check binary. It doesn't replace esbuild, swc, or next build. Most modern monorepos already separated type-checking from transpilation — if yours hasn't, this is the moment to do it regardless of tsgo.

# Separating type-check from build in CI — recommended pattern today
# Step 1: type-check (candidate for tsgo when stable)
pnpm tsc --noEmit --project tsconfig.json

# Step 2: build/transpilation (keep using tsc or next build, not tsgo yet)
pnpm next build

Mistake 3: ignoring the Language Service. Several enthusiastic posts recommend switching VS Code's typescript.tsdk to point at tsgo. The result today is inconsistent — some features work, others don't. Unless you're deliberately experimenting, don't do it in an environment where you need to actually develop.

Mistake 4: losing sight of the fact that plugins matter. Next.js 15+ ships its own TypeScript plugin to correctly type Server Component props and generateMetadata parameters. If tsgo doesn't load it, you lose those checks. That's not a tsgo problem — it's a documented beta limitation you need to track before adopting it.

Decision matrix: when to explore tsgo today

Not every tooling decision needs a spreadsheet. This one does need clear criteria because the cost of a premature migration is real: breaking your editor's feedback loop exactly when you need it most.

Situation	Recommendation
CI type-check > 5 minutes	Worth exploring tsgo in a separate job and comparing
CI type-check < 2 minutes	Wait for stable — no urgent gain
Monorepo with complex project references	Wait — documented partial support
Next.js project with its TS plugin	Wait — plugins not guaranteed in beta
Pure type-check (`--noEmit`) in a separate CI job	Most mature case to try today
Need Language Server in your editor	Not yet — LSP incomplete

The only scenario where I see immediate value is a CI pipeline where type-checking is the documented bottleneck and you can run tsgo in a parallel job without touching the main build. That way you explore without risk.

# Example parallel job in GitHub Actions to evaluate tsgo
# Without touching the main build
jobs:
  typecheck-experimental:
    runs-on: ubuntu-latest
    continue-on-error: true  # doesn't block the pipeline if tsgo fails
    steps:
      - uses: actions/checkout@v4
      - name: Install Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.22'
      - name: Clone and build tsgo
        run: |
          git clone https://github.com/microsoft/typescript-go /tmp/tsgo
          cd /tmp/tsgo && go build ./cmd/tsgo
      - name: Measure type-check time with tsgo
        run: |
          time /tmp/tsgo/tsgo --project tsconfig.json
      - name: Measure type-check time with tsc (for comparison)
        run: |
          time pnpm tsc --noEmit

This approach has one concrete advantage: you get real data from your project, not from Microsoft's benchmark. That difference matters.

What you can't conclude without your own experiment

The uncomfortable thing about this topic is that the public evidence backs the speed claim but can't tell you how much your specific pipeline will improve. It depends on file count, type complexity, whether you're using heavy conditional types, how many paths your tsconfig has, and whether you have plugins tsgo won't load.

What you can conclude without experimenting:

tsgo will not change error semantics — same type system specification
tsgo is not a drop-in replacement today — documented limitations in the official repo
The technical bet of rewriting in Go has solid justification beyond the marketing: native parallelism, binary without V8, different memory management

What you need to measure yourself:

Real time gains on your specific codebase
Whether the plugins you use are supported
Language Service behavior in your editor

Without those three measurements, any claim of "migrate it now" or "it's worthless" is noise.

FAQ: tsgo typescript compiler go

Does tsgo completely replace tsc today?
No. In the current beta, tsgo is primarily a CLI type-checker (--noEmit). It doesn't replace code emission, TypeScript plugins, and doesn't have full Language Service parity for editors. The official repository documents the roadmap with what's still missing.

Is tsgo's type system identical to the original TypeScript?
Yes, that's the project's premise. The Go port replicates the same type semantics — the same errors, the same inferences, the same strict behavior. If you find a difference, it's a bug in the port, not a feature.

Does it work with Next.js?
Partially. Basic type-checking works, but the TypeScript plugin Next.js includes to type Server Components and metadata isn't guaranteed in the beta. For production Next.js projects, wait until plugin support is stable.

Is it worth trying in a monorepo with pnpm workspaces?
Depends on the size. If you have project references (composite: true) between packages, support is partial per the official documentation. If you're simply running tsc --noEmit on the root, that's the most mature scenario to experiment with.

When will it hit stable?
The official repository's roadmap has no public date. The signal to watch for: complete LSP, verified plugin support, and documented parity with tsc. Follow the repo — the milestones are public.

Should I switch VS Code's typescript.tsdk to tsgo now?
I wouldn't do it in an active development environment. The tsgo Language Service in beta has incomplete features that will break hover types and autocomplete in specific cases. If you want to experiment, do it on a dedicated branch with that explicit purpose.

My take and the one concrete next step

tsgo is the most technically interesting move in the TypeScript ecosystem in years. Not because the "10x" number is magic, but because the real bottleneck of the compiler was always the JavaScript runtime — and that limitation now has a serious answer with public evidence behind it.

What I don't buy is the enthusiasm that ignores the documented limitations. The current beta has a clear scope: CLI type-checking on projects without complex plugins. That's not nothing — for many CI pipelines it's exactly the critical use case — but it's also not the full replacement some posts present it as.

My practical recommendation: if type-checking is the documented bottleneck in your CI, set up a parallel job with continue-on-error: true, measure the delta on your real codebase, and make the decision with your own data. If you don't have that problem today, close this tab and revisit it when the team announces stable. There's no urgency.

The next step for you is exactly one thing: go to the official repository and check the open issues for the features you actually use. That's where the real information is — not in the headlines.

Original sources:

TypeScript Go — GitHub Repository: https://github.com/microsoft/typescript-go
TypeScript Blog — Announcing TypeScript Go: https://devblogs.microsoft.com/typescript/typescript-native-port/

This article was originally published on juanchi.dev

tsgo: qué cambia en el compilador TypeScript reescrito en Go y qué significa para proyectos reales

Juan Torchia — Tue, 02 Jun 2026 14:31:53 +0000

tsgo: qué cambia en el compilador TypeScript reescrito en Go y qué significa para proyectos reales

Cometí el error de descartar tsgo como hype antes de leerlo. Vi el titular "10x más rápido" y lo puse en la misma carpeta mental que los benchmarks de frameworks JavaScript: números reales en un contexto que nada tiene que ver con lo mío. Me alcanzó con abrir el repositorio oficial y el anuncio del equipo de TypeScript para entender que esta vez la historia es distinta — y que vale la pena entender exactamente qué cambió, qué todavía no, y cuándo tiene sentido explorar la migración.

Mi tesis es simple: tsgo es una apuesta técnica legítima con evidencia pública que la respalda, pero la beta tiene limitaciones documentadas que la mayoría de los posts entusiastas omiten. El criterio para migrarlo hoy no es si el número te parece atractivo — es si tu CI tarda más de 5 minutos en type-check. Si no llegás a ese umbral, esperá la stable y dormí tranquilo.

tsgo typescript compiler go: qué es y de dónde viene

El proyecto oficial vive en github.com/microsoft/typescript-go. No es un fork ni un experimento de comunidad: es el propio equipo de TypeScript portando el compilador a Go nativo, con el objetivo declarado de aprovechar paralelismo real y eliminar el overhead de V8.

El anuncio oficial en el TypeScript Blog es claro sobre el razonamiento: JavaScript tiene un techo en cuanto a velocidad de compilación porque corre sobre un runtime de propósito general. Go permite compilar a binario nativo, gestionar goroutines para paralelismo genuino y evitar la presión del garbage collector de V8. El resultado según las mediciones del propio equipo: compilaciones que en TypeScript clásico toman decenas de segundos bajan a pocos segundos o menos.

Lo importante es que tsgo no cambia el sistema de tipos. La semántica de TypeScript — los mismos errores, las mismas inferencias, el mismo comportamiento de strict — sigue siendo idéntica. Lo que cambia es la velocidad con la que llegás a esos resultados.

# Instalación experimental según el repo oficial
# No está en npm stable todavía — seguí el README del repo
git clone https://github.com/microsoft/typescript-go
cd typescript-go

# Compilar el binario (requiere Go instalado)
go build ./cmd/tsgo

# Correr type-check sobre un proyecto
./tsgo --project ruta/a/tsconfig.json

Qué limitaciones tiene la beta hoy

Acá es donde la mayoría de los posts se quedan cortos. El roadmap del repositorio oficial documenta explícitamente qué no está listo en la beta:

Language Service (LSP) incompleto. La integración con editores — VS Code, Neovim, cualquier cliente LSP — está en progreso pero no tiene paridad con tsc. Esto significa que no podés reemplazar hoy el servidor de lenguaje que te da hover types, go-to-definition y autocompletado. El type-check de CLI es lo más maduro.

Build mode y project references. El soporte para tsc --build con composite: true y references entre paquetes de un monorepo está parcialmente implementado. Si usás pnpm workspaces con múltiples tsconfig.json enlazados, vas a encontrar casos borde.

Plugins de TypeScript. Los plugins del tsconfig.json que muchos frameworks usan internamente (Next.js incluye el suyo) no tienen soporte garantizado todavía.

Transformaciones de código. tsgo en beta es un type-checker, no un transpiler completo. No reemplaza a tsc cuando necesitás emitir .js desde .ts con transformaciones. Eso sigue siendo territorio del compilador original o de herramientas como esbuild/swc.

// tsconfig.json típico en un proyecto Next.js con strict mode
// Lo que tsgo puede type-checkear hoy (CLI)
{
  "compilerOptions": {
    "strict": true,
    "noEmit": true,         // ← modo "solo type-check, no emitir" — el caso más maduro en tsgo
    "target": "ESNext",
    "moduleResolution": "Bundler",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}
// Lo que NO está listo: plugins como el de Next.js, composite + references complejos

Si tenés strict: true activo — y si no sabés por qué deberías, tengo un post sobre las opciones del tsconfig que más impactan en producción — tsgo respeta exactamente esa semántica. El port no relaja ni cambia los checks.

Los errores comunes al evaluar tsgo

Error 1: comparar el número sin contexto de proyecto. El "10x" viene de benchmarks con codebases grandes. En un proyecto de 50 archivos donde tsc --noEmit tarda 8 segundos, el salto va a ser perceptible pero no dramático. En un monorepo con 500+ archivos donde el type-check en CI tarda 4-6 minutos, la diferencia cambia el pipeline de forma concreta.

Error 2: asumir que reemplaza toda la cadena de herramientas. tsgo en beta es un binario de type-check. No reemplaza esbuild, swc, ni el next build. La mayoría de los monorepos modernos ya separaron type-check de transpilación — si el tuyo no, este es el momento de hacerlo independientemente de tsgo.

# Separar type-check de build en CI — patrón recomendado hoy
# Paso 1: type-check (candidato para tsgo cuando sea stable)
pnpm tsc --noEmit --project tsconfig.json

# Paso 2: build/transpilación (sigue con tsc o next build, no tsgo todavía)
pnpm next build

Error 3: ignorar el Language Service. Varios posts de entusiasmo recomiendan cambiar el typescript.tsdk de VS Code apuntando a tsgo. El resultado hoy es inconsistente: algunas features funcionan, otras no. A menos que estés experimentando conscientemente, no lo hagas en un entorno donde necesitás desarrollar.

Error 4: perder de vista que los plugins importan. Next.js 15+ usa un plugin TypeScript propio para tipear correctamente los props de Server Components y los parámetros de generateMetadata. Si tsgo no lo carga, vas a perder esos checks. Eso no es un problema de tsgo — es una limitación documentada de la beta que hay que rastrear antes de adoptarlo.

Matriz de decisión: cuándo explorar tsgo hoy

No toda decisión de herramienta necesita una hoja de cálculo. Esta sí necesita criterio claro porque el costo de una migración prematura es real: romper el feedback loop del editor justo cuando más lo necesitás.

Situación	Recomendación
CI type-check > 5 minutos	Vale explorar tsgo en un job separado y comparar
CI type-check < 2 minutos	Esperá la stable, no hay ganancia urgente
Monorepo con project references complejas	Esperá — soporte parcial documentado
Proyecto con Next.js y su plugin TS	Esperá — plugins no garantizados en beta
Quizás type-check puro (`--noEmit`) en CI separado	Caso más maduro hoy para probar
Necesitás Language Server en editor	No todavía — LSP incompleto

El único escenario donde veo valor inmediato es un pipeline de CI donde el type-check es el cuello de botella documentado y podés correr tsgo en un job paralelo sin afectar el build principal. Así explorás sin riesgo.

# Ejemplo de job paralelo en GitHub Actions para evaluar tsgo
# Sin tocar el build principal
jobs:
  typecheck-experimental:
    runs-on: ubuntu-latest
    continue-on-error: true  # no bloquea el pipeline si tsgo falla
    steps:
      - uses: actions/checkout@v4
      - name: Instalar Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.22'
      - name: Clonar y compilar tsgo
        run: |
          git clone https://github.com/microsoft/typescript-go /tmp/tsgo
          cd /tmp/tsgo && go build ./cmd/tsgo
      - name: Medir time-check con tsgo
        run: |
          time /tmp/tsgo/tsgo --project tsconfig.json
      - name: Medir time-check con tsc (para comparar)
        run: |
          time pnpm tsc --noEmit

Este approach tiene una ventaja concreta: obtenés datos reales de tu proyecto, no del benchmark de Microsoft. Esa diferencia importa.

Qué no podés concluir sin experimento propio

Lo incómodo de este tema es que la evidencia pública respalda el claim de velocidad pero no puede decirte cuánto va a mejorar tu pipeline específico. Depende de la cantidad de archivos, la complejidad de tipos, si usás conditional types pesados, cuántos paths tiene el tsconfig, y si tenés plugins que tsgo no carga.

Lo que sí podés concluir sin experimento:

tsgo no va a cambiar la semántica de los errores — misma especificación del sistema de tipos
tsgo no es un reemplazo drop-in hoy — tiene limitaciones documentadas en el repo oficial
La apuesta técnica de reescribir en Go tiene justificación sólida más allá del marketing: paralelismo nativo, binario sin V8, gestión de memoria diferente

Lo que necesitás medir vos mismo:

Ganancia real de tiempo en tu codebase específica
Si los plugins que usás están soportados
Comportamiento del Language Service en tu editor

Sin esas tres mediciones, cualquier claim de "migralo ya" o "no vale nada" es ruido.

FAQ: tsgo typescript compiler go

¿tsgo reemplaza completamente a tsc hoy?
No. En la beta actual, tsgo es principalmente un type-checker de CLI (--noEmit). No reemplaza la emisión de código, los plugins de TypeScript ni tiene paridad completa en el Language Service para editores. El repositorio oficial documenta el roadmap con lo que falta.

¿El sistema de tipos de tsgo es idéntico al de TypeScript original?
Sí, esa es la premisa del proyecto. El port a Go replica la misma semántica de tipos — los mismos errores, las mismas inferencias, el mismo comportamiento de strict. Si encontrás una diferencia, es un bug del port, no un feature.

¿Funciona con Next.js?
Parcialmente. El type-check básico funciona, pero el plugin TypeScript que Next.js incluye para tipar Server Components y metadata no está garantizado en la beta. Para proyectos Next.js en producción, esperá que el soporte de plugins esté estable.

¿Vale la pena probarlo en un monorepo con pnpm workspaces?
Depende del tamaño. Si tenés project references (composite: true) entre paquetes, el soporte es parcial según la documentación oficial. Si simplemente corrés tsc --noEmit sobre el root, es el escenario más maduro para experimentar.

¿Cuándo va a estar en stable?
El roadmap del repositorio oficial no tiene fecha pública. La señal para esperar es: LSP completo, soporte de plugins verificado y paridad documentada con tsc. Seguí el repo — los milestones están públicos.

¿Cambio el typescript.tsdk de VS Code a tsgo ya?
No lo haría en un entorno de desarrollo activo. El Language Service de tsgo en beta tiene features incompletas que van a romper el hover types y el autocompletado en casos específicos. Si querés experimentar, hacelo en una branch dedicada con ese propósito.

Mi postura y el próximo paso concreto

tsgo es la movida técnica más interesante del ecosistema TypeScript en años. No porque el número "10x" sea mágico, sino porque el cuello de botella real del compilador siempre fue el runtime de JavaScript — y esa limitación ahora tiene una respuesta seria con evidencia pública.

Lo que no compro es el entusiasmo que ignora las limitaciones documentadas. La beta actual tiene un scope claro: type-check de CLI en proyectos sin plugins complejos. Eso no es poca cosa — para muchos pipelines de CI es exactamente el caso de uso crítico — pero tampoco es el reemplazo completo que algunos posts presentan.

Mi recomendación práctica: si el type-check es el cuello de botella documentado en tu CI, armá un job paralelo con continue-on-error: true, medí el delta en tu codebase real y tomá la decisión con datos propios. Si no tenés ese problema hoy, cerrá esta pestaña y revisalo cuando el equipo anuncie la stable. No hay urgencia.

El próximo paso para vos es uno solo: entrar al repositorio oficial y revisar los issues abiertos de las features que usás. Ahí está la información real, no en los titulares.

Fuentes originales:

TypeScript Go — GitHub Repository: https://github.com/microsoft/typescript-go
TypeScript Blog — Announcing TypeScript Go: https://devblogs.microsoft.com/typescript/typescript-native-port/

Este artículo fue publicado originalmente en juanchi.dev

React 19 use() hook and Suspense: when it replaces useEffect and when it throws you into a worse loop

Juan Torchia — Tue, 02 Jun 2026 12:01:07 +0000

React 19 use() hook and Suspense: when it replaces useEffect and when it throws you into a worse loop

You can wrap a Promise in use() and React handles the loading state by itself. Yeah, you read that right. And yet, 40% of the components I started migrating I ended up reverting. Not because use() is bad — it's genuinely good — but because Suspense has error semantics that most Twitter examples skip entirely.

My thesis from the start: use() is a real improvement for specific cases, but it doesn't replace useEffect universally. The line between the two isn't "how much code you save" — it's what happens when the Promise rejects.

What React 19 use hook Suspense actually is and what the official docs really say

According to the official React documentation, use() is a hook that reads the value of a resource: a Promise or a Context. When it receives a Promise, it suspends the component until it resolves and delegates the loading state to the nearest <Suspense>.

What the docs do clarify — and this is worth reading carefully — is this:

"If the Promise rejects, React will throw the rejection reason. You can handle rejection using an Error Boundary."

That's where the friction starts. use() doesn't give you a local error state. There's no catch in the component. The error bubbles up to the nearest Error Boundary and unmounts the entire subtree. That might be exactly what you want, or it might be a structural problem depending on how you've organized your boundaries in the tree.

// Basic pattern with use() — works great for this
import { use, Suspense } from "react";

// The Promise comes from outside the component (key: not created inside)
function UserProfile({ userPromise }: { userPromise: Promise<User> }) {
  // use() suspends until resolved; if it rejects, bubbles to Error Boundary
  const user = use(userPromise);
  return <h1>{user.name}</h1>;
}

export default function Page() {
  return (
    <ErrorBoundary fallback={<p>Error loading profile</p>}>
      <Suspense fallback={<p>Loading...</p>}>
        <UserProfile userPromise={fetchUser()} />
      </Suspense>
    </ErrorBoundary>
  );
}

This works perfectly. The component is declarative, has no side effects, and Suspense shows the fallback while it resolves. Welcome to React 19.

The two cases where use() makes things more complicated, not less

Case 1: the Promise is created inside the component

This is the most common mistake and the one I've seen most often in blog examples:

// ⚠️ THIS CAUSES AN INFINITE SUSPENSE LOOP
function Profile() {
  // Every render creates a new Promise → use() suspends → React re-renders → new Promise
  const user = use(fetchUser()); // ← PROBLEM: new Promise on every render
  return <h1>{user.name}</h1>;
}

If the Promise is created inside the component, every render produces a new instance. use() suspends it, React re-renders to resolve, creates another Promise… loop. The fix is to hoist the Promise outside the component or memoize it with useMemo, but at that point you're adding complexity that useEffect never required.

The React 19 documentation mentions it: Promises must be created outside the component or be stable across renders. It's not a bug — it's part of the hook's contract.

// ✅ Correct: stable Promise, created outside the component
const globalPromise = fetchUser(); // outside the render tree

function Profile() {
  const user = use(globalPromise);
  return <h1>{user.name}</h1>;
}

Case 2: an Error Boundary that catches more than you want

The second case is subtler and more expensive to diagnose. Imagine a layout with multiple independent sections: profile, notifications, and settings. If all three use use() and share a single Error Boundary, one section failing takes down all three.

// Problematic tree: one Error Boundary for everything
<ErrorBoundary fallback={<GeneralError />}>
  <Suspense fallback={<Skeleton />}>
    <ProfileWithUse />       {/* if this fails, everything goes down */}
    <NotificationsWithUse />
    <SettingsWithUse />
  </Suspense>
</ErrorBoundary>

With useEffect, each component has its own local error state and can show an inline message without affecting the others. With use(), error isolation depends entirely on how many granular Error Boundaries you have in the tree.

// ✅ Correct tree to isolate errors with use()
<>
  <ErrorBoundary fallback={<ProfileError />}>
    <Suspense fallback={<ProfileSkeleton />}>
      <ProfileWithUse />
    </Suspense>
  </ErrorBoundary>

  <ErrorBoundary fallback={<NotificationsError />}>
    <Suspense fallback={<NotifSkeleton />}>
      <NotificationsWithUse />
    </Suspense>
  </ErrorBoundary>
</>

It works. But now the cost of migrating isn't just swapping useEffect for use() — it's auditing and probably refactoring your entire Error Boundary structure across the tree. That can be a lot of work for components that already work fine.

The most common diagnostic mistakes

"use() is a direct replacement for useEffect for fetching" — Not exactly. useEffect for fetching has its own problems (I broke that down in the post about useEffect), but it has local error state. use() delegates the error to the tree. Those are different contracts.

"With Suspense, the loading state disappears" — The loading state doesn't disappear: it moves to the fallback of the nearest <Suspense>. If that fallback is too broad, the UX can actually get worse — an entire section disappears while loading a small piece of data.

"use() works for any async" — use() can be called conditionally (unlike other hooks), but that doesn't mean it works for every pattern. Mutations, effects with cleanup, external event subscribers, and intervals still need useEffect. The official documentation is clear: use() reads resources, it doesn't execute effects.

Gotcha with Next.js App Router: in Server Components, data fetching is direct async/await — no use(). The hook applies in Client Components. Mixing both contexts without understanding the difference produces errors that are hard to read. If you're coming from the pages router, this mental model shift is the biggest friction point.

Decision checklist: use() or useEffect?

Before migrating a component, run through these questions:

Criterion	use()	useEffect
Can the Promise be created outside the component or is it stable?	✅	—
Does each section have its own granular Error Boundary?	✅	—
Do you need inline error handling (without unmounting the component)?	—	✅
Is it an effect with cleanup (subscription, interval, listener)?	—	✅
Does the data come from a Server Component as a prop?	✅	—
Should the loading state be local to the component?	—	✅
Is it a mutation (POST, PUT, DELETE)?	—	✅ (or useActionState)

If the first two questions don't have a ✅, think twice before migrating.

Real limits of this guide

What I can't claim without concrete production logs:

I don't have my own benchmark numbers or compared render-time metrics. If you need that evidence, the discussion in React's issue tracker has more context than any blog post.
The behavior with React Server Components in Next.js 16 can vary depending on the bundler version and cache configuration. What applies today might change in a minor update.
Granular Error Boundary patterns have a maintenance cost that depends on team size and tree complexity. There's no universal number.

What is verifiable and reproducible: both cases from the section above you can test locally in minutes. Create a component with an unstable Promise and a tree with a single Error Boundary. The behavior will be exactly what I described.

FAQ — React 19 use hook Suspense

Does use() completely replace useEffect for data fetching?
No. use() replaces the useEffect + loading state pattern for cases where the Promise is stable and the tree has well-organized Error Boundaries. For effects with cleanup, mutations, or inline error handling, useEffect is still the right tool.

Can use() be called conditionally?
Yes, unlike other hooks. You can call it inside an if or a loop. That makes it useful for patterns where the resource to read depends on a condition, but it doesn't turn it into a general control-flow handler.

What happens if the Promise rejects and there's no Error Boundary?
React logs an error in the console and unmounts the component. In development, the error overlay appears immediately. In production, the user sees a blank screen if there's no Error Boundary anywhere in the tree. That's why boundary management isn't optional with use().

Does use() work in Server Components?
Not directly. In Next.js App Router Server Components, data fetching is native async/await. use() applies in Client Components. Mixing them requires understanding the "use client" boundary and how data gets passed down as props.

What's the difference between use() and SWR or React Query for fetching?
SWR and React Query add caching, revalidation, request deduplication, and advanced error handling that use() doesn't provide. For data that changes, revalidates, or is shared across components, a fetching library is still more complete. use() is a runtime primitive, not a data client.

Can use() read Contexts as well as Promises?
Yes. use(MyContext) is equivalent to useContext(MyContext) with the advantage that it can be called conditionally. For contexts that change infrequently, the difference is minimal. For contexts that change often with conditional logic, it can simplify the code.

Conclusion: when to migrate and when to leave it alone

use() is one of the best additions in React 19. Declaring a component that reads data without useState + useEffect + manual loading handling is genuinely cleaner. I'm not disputing that.

What I don't buy is the framing of "replace all your fetch useEffects with use()." The error contract with Suspense implies a responsibility that many component trees aren't ready to take on without prior refactoring. The cost of that refactoring can outweigh the benefit in components that already work well.

My personal criterion: migrate to use() when the Promise comes from outside the component (Server Component, cache, stable context), when you already have granular Error Boundaries, or when you're building the component from scratch. Don't migrate when the component has inline error handling the user sees in a localized way, or when the Promise depends on local state that changes frequently.

If you're designing the architecture of a shared data system across components, the post on backend architecture and decisions tutorials leave out has complementary context on how error contracts propagate through layers. And if you're working with TypeScript strict in that same project, the 6 tsconfig options that impact production the most will be relevant when typing the Promises you pass to use().

The concrete next step: open a component that uses useEffect for fetching, run it through the checklist above, and decide with criteria. Not with ecosystem momentum.

Original sources:

React Docs — use(): https://react.dev/reference/react/use
React 19 Release Notes: https://react.dev/blog/2024/12/05/react-19

This article was originally published on juanchi.dev

React 19 use() hook y Suspense: cuándo reemplaza useEffect y cuándo te mete en un loop peor

Juan Torchia — Tue, 02 Jun 2026 12:01:02 +0000

React 19 use() hook y Suspense: cuándo reemplaza useEffect y cuándo te mete en un loop peor

Podés envolver una Promise en use() y React maneja el loading state solo. Sí, leíste bien. Y sin embargo, el 40% de los componentes que arranqué a migrar los terminé revirtiendo. No porque use() sea malo — es genuinamente bueno — sino porque Suspense tiene una semántica de error que la mayoría de los ejemplos en Twitter omite completamente.

Mi tesis desde el arranque: use() es una mejora real para casos específicos, pero no reemplaza useEffect de forma universal. El criterio que separa ambos casos no es "cuánto código ahorrás" sino qué pasa cuando la Promise rechaza.

Qué es react 19 use hook suspense y qué dice realmente la doc oficial

Según la documentación oficial de React, use() es un hook que lee el valor de un recurso: una Promise o un Context. Cuando recibe una Promise, suspende el componente hasta que se resuelve y delega el estado de carga al <Suspense> más cercano.

Lo que la doc sí aclara — y que conviene leer con cuidado — es esto:

"If the Promise rejects, React will throw the rejection reason. You can handle rejection using an Error Boundary."

Ahí empieza la fricción. use() no te da un estado error local. No hay catch en el componente. El error sube hasta el Error Boundary más cercano y desmonta toda la subárbol. Eso puede ser exactamente lo que querés, o puede ser un problema estructural dependiendo de cómo organizaste los boundaries en el árbol.

// Patrón básico con use() — funciona bien para esto
import { use, Suspense } from "react";

// La Promise viene de afuera del componente (clave: no se crea adentro)
function PerfilUsuario({ promesaUsuario }: { promesaUsuario: Promise<Usuario> }) {
  // use() suspende hasta resolver; si rechaza, sube al Error Boundary
  const usuario = use(promesaUsuario);
  return <h1>{usuario.nombre}</h1>;
}

export default function Pagina() {
  return (
    <ErrorBoundary fallback={<p>Error cargando perfil</p>}>
      <Suspense fallback={<p>Cargando...</p>}>
        <PerfilUsuario promesaUsuario={fetchUsuario()} />
      </Suspense>
    </ErrorBoundary>
  );
}

Esto funciona perfecto. El componente es declarativo, no tiene efectos secundarios y Suspense muestra el fallback mientras resuelve. Bienvenido a React 19.

Los dos casos donde use() complica más de lo que simplifica

Caso 1: la Promise se crea dentro del componente

Este es el error más común y el que más veces vi en ejemplos de blog:

// ⚠️ ESTO CAUSA UN LOOP INFINITO DE SUSPENSE
function Perfil() {
  // Cada render crea una Promise nueva → use() suspende → React re-renderiza → nueva Promise
  const usuario = use(fetchUsuario()); // ← PROBLEMA: Promise nueva en cada render
  return <h1>{usuario.nombre}</h1>;
}

Si la Promise se crea dentro del componente, cada render produce una instancia nueva. use() la suspende, React re-renderiza para resolver, crea otra Promise... loop. La solución es elevar la Promise fuera del componente o memoizarla con useMemo, pero en ese punto estás agregando complejidad que useEffect no requería.

La documentación de React 19 lo menciona: las Promises deben crearse fuera del componente o ser estables entre renders. No es un bug, es parte del contrato del hook.

// ✅ Correcto: Promise estable, creada fuera del componente
const promesaGlobal = fetchUsuario(); // fuera del árbol de render

function Perfil() {
  const usuario = use(promesaGlobal);
  return <h1>{usuario.nombre}</h1>;
}

Caso 2: Error Boundary que captura más de lo que querés

El segundo caso es más sutil y más costoso de diagnosticar. Imaginá un layout con múltiples secciones independientes: perfil, notificaciones y configuración. Si las tres usan use() y comparten un único Error Boundary, el fallo de una sección desmonta las tres.

// Árbol problemático: un Error Boundary para todo
<ErrorBoundary fallback={<ErrorGeneral />}>
  <Suspense fallback={<Skeleton />}>
    <PerfilConUse />       {/* si falla, baja todo */}
    <NotificacionesConUse />
    <ConfigConUse />
  </Suspense>
</ErrorBoundary>

Con useEffect, cada componente tiene su propio error state local y puede mostrar un mensaje inline sin afectar a los demás. Con use(), el aislamiento de errores depende de cuántos Error Boundaries granulares tengas en el árbol.

// ✅ Árbol correcto para aislar errores con use()
<>
  <ErrorBoundary fallback={<ErrorPerfil />}>
    <Suspense fallback={<SkeletonPerfil />}>
      <PerfilConUse />
    </Suspense>
  </ErrorBoundary>

  <ErrorBoundary fallback={<ErrorNotificaciones />}>
    <Suspense fallback={<SkeletonNotif />}>
      <NotificacionesConUse />
    </Suspense>
  </ErrorBoundary>
</>

Funciona. Pero ahora el costo de migrar no es solo cambiar useEffect por use(): es auditar y probablemente refactorizar toda la estructura de Error Boundaries del árbol. Eso puede ser mucho trabajo para componentes que ya funcionan bien.

Errores de diagnóstico más frecuentes

"use() es un reemplazo directo de useEffect para fetch" — No exactamente. useEffect para fetch tiene sus propios problemas (lo analicé en el post sobre useEffect), pero tiene error state local. use() delega el error al árbol. Son contratos distintos.

"Con Suspense, el loading state desaparece" — El loading state no desaparece: se mueve al fallback del <Suspense> más cercano. Si ese fallback es demasiado amplio, el UX puede empeorar: toda una sección desaparece mientras carga un dato pequeño.

"use() funciona para cualquier async" — use() puede llamarse condicionalmente (a diferencia de otros hooks), pero eso no significa que sirva para cualquier patrón. Las mutaciones, los efectos con cleanup, los suscriptores a eventos externos y los intervalos siguen necesitando useEffect. La documentación oficial es clara en que use() lee recursos, no ejecuta efectos.

Gotcha con Next.js App Router: en Server Components, el data fetching es async/await directo, sin use(). El hook aplica en Client Components. Mezclar los dos contextos sin entender la diferencia produce errores difíciles de leer. Si venís de pages router, este cambio de mental model es la fricción más grande.

Checklist de decisión: ¿use() o useEffect?

Antes de migrar un componente, pasá por estas preguntas:

Criterio	use()	useEffect
¿La Promise puede crearse fuera del componente o es estable?	✅	—
¿Cada sección tiene su propio Error Boundary granular?	✅	—
¿Necesitás manejo de error inline (sin desmontar el componente)?	—	✅
¿Es un efecto con cleanup (subscripción, intervalo, listener)?	—	✅
¿El dato viene de un Server Component como prop?	✅	—
¿El estado de carga debe ser local al componente?	—	✅
¿Es una mutación (POST, PUT, DELETE)?	—	✅ (o useActionState)

Si las primeras dos preguntas no tienen ✅, pensalo dos veces antes de migrar.

Límites reales de esta guía

Lo que no puedo afirmar sin logs de producción concretos:

No hay números propios de benchmarks ni métricas de tiempo de render comparadas. Si necesitás esa evidencia, la discusión en el issue tracker de React tiene más contexto que cualquier blog.
El comportamiento con React Server Components en Next.js 16 puede variar según la versión del bundler y la configuración de caché. Lo que aplica hoy puede cambiar en una actualización menor.
Los patrones de Error Boundary granular tienen un costo de mantenimiento que depende del tamaño del equipo y la complejidad del árbol. No hay un número universal.

Lo que sí es verificable y reproducible: los dos casos de la sección anterior podés testarlos localmente en minutos. Creá un componente con una Promise inestable y un árbol con un único Error Boundary. El comportamiento va a ser exactamente el que describí.

FAQ — react 19 use hook suspense

¿use() reemplaza completamente useEffect para data fetching?
No. use() reemplaza el patrón de useEffect + estado de carga para casos donde la Promise es estable y el árbol tiene Error Boundaries bien organizados. Para efectos con cleanup, mutaciones o manejo de error inline, useEffect sigue siendo la herramienta correcta.

¿use() se puede llamar condicionalmente?
Sí, a diferencia de otros hooks. Podés llamarlo dentro de un if o un loop. Eso lo hace útil para patrones donde el recurso a leer depende de una condición, pero no lo convierte en manejador de flujo de control general.

¿Qué pasa si la Promise rechaza y no hay Error Boundary?
React muestra un error en consola y desmonta el componente. En desarrollo, el overlay de error aparece inmediatamente. En producción, el usuario ve pantalla en blanco si no hay un Error Boundary en algún nivel del árbol. Por eso la gestión de boundaries no es opcional con use().

¿use() funciona en Server Components?
No directamente. En Server Components de Next.js App Router, el data fetching es async/await nativo. use() aplica en Client Components. Mezclarlos requiere entender el límite "use client" y cómo se pasan datos como props.

¿Cuál es la diferencia entre use() y SWR o React Query para fetching?
SWR y React Query agregan caché, revalidación, deduplicación de requests y manejo de errores avanzado que use() no provee. Para datos que cambian, se revalidan o se comparten entre componentes, una librería de fetching sigue siendo más completa. use() es primitivo del runtime, no un cliente de datos.

¿use() puede leer Contexts además de Promises?
Sí. use(MiContext) es equivalente a useContext(MiContext) con la ventaja de que puede llamarse condicionalmente. Para contextos que cambian poco, la diferencia es mínima. Para contextos que cambian frecuentemente con lógica condicional, puede simplificar el código.

Conclusión: cuándo migrar y cuándo no moverse

use() es una de las mejores adiciones de React 19. Declarar un componente que lee datos sin useState + useEffect + manejo manual de loading es genuinamente más limpio. No lo discuto.

Lo que no compro es el framing de "reemplazá todos los useEffect de fetch con use()". El contrato de error con Suspense implica una responsabilidad que muchos árboles de componentes no están listos para asumir sin refactoring previo. El costo de esa refactorización puede superar el beneficio en componentes que ya funcionan bien.

Mi criterio personal: migrá a use() cuando la Promise viene de afuera del componente (Server Component, cache, contexto estable), cuando ya tenés Error Boundaries granulares o cuando estés construyendo el componente desde cero. No migrés cuando el componente tiene manejo de error inline que el usuario ve de forma localizada, o cuando la Promise depende de estado local que cambia frecuentemente.

Si estás diseñando la arquitectura de un sistema de datos compartidos entre componentes, el post sobre arquitectura backend y decisiones que los tutoriales omiten tiene contexto complementario sobre cómo los contratos de error se propagan en capas. Y si trabajás con TypeScript strict en ese mismo proyecto, las 6 opciones de tsconfig que más impactan en producción van a ser relevantes al tipar las Promises que le pasás a use().

El próximo paso concreto: abrí un componente que use useEffect para fetch, pasalo por el checklist de arriba y decidí con criterio. No con momentum de ecosystem.

Fuentes originales:

React Docs — use(): https://react.dev/reference/react/use
React 19 Release Notes: https://react.dev/blog/2024/12/05/react-19

Este artículo fue publicado originalmente en juanchi.dev

Spring Boot Actuator: What to Expose, What to Hide, and What to Check Before Adding Endpoints

Juan Torchia — Mon, 01 Jun 2026 12:02:33 +0000

Spring Boot Actuator: What to Expose, What to Hide, and What to Check Before Adding Endpoints

I was reviewing a Spring Boot backend config in a test environment when I noticed /actuator/env was responding without authentication. Nothing production, nothing critical — but the setup was the classic default of someone who added the dependency, saw /actuator/health working, and moved on. The env endpoint exposes active environment variables, including everything in the Spring context. In a real environment, that can mean interpolated credentials, internal URLs, or feature flags that have no business being public.

My thesis is this: Actuator isn't bad. It's a serious, well-documented, genuinely useful operational tool. The mistake is adding it without deciding what you want to expose, to whom, and with what restrictions. Most tutorials tell you how to enable it. Almost none explain the cost of enabling it wrong.

Spring Boot Actuator endpoint security: what the official docs actually say

The official Spring Boot Actuator documentation is explicit about something a lot of people ignore: endpoints have two independent dimensions — being enabled and being exposed.

An endpoint can be enabled (active in the application context) but not exposed over HTTP. By default, only health is exposed via HTTP. Everything else requires explicit configuration.

That matters because the default behavior is conservative — but trivially easy to override with a single line:

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: "*"  # Exposes EVERYTHING — including what you don't want exposed

That line shows up in hundreds of tutorials as "to see all available endpoints." Which is fine on localhost. It's a problem if it makes it to a shared environment or production without review.

The docs also distinguish between JMX and HTTP as separate exposure channels. By default, JMX exposes all enabled endpoints, while HTTP is more restrictive. If your application isn't actively using JMX, it's worth disabling that channel too.

The endpoints that deserve attention before you expose them

Endpoint	What it exposes	Risk if public
`/actuator/env`	Spring context environment variables	High — can include credentials
`/actuator/beans`	All registered beans	Medium — reveals internal architecture
`/actuator/heapdump`	JVM heap dump	High — can contain sensitive data in heap
`/actuator/mappings`	All HTTP endpoints in the app	Medium — enables reconnaissance
`/actuator/loggers`	Active logging configuration	Low-Medium — allows runtime log level changes
`/actuator/metrics`	JVM and app metrics	Low — useful internally, little value exposed
`/actuator/health`	App operational status	Low if properly configured

This table isn't exhaustive — the full list of built-in endpoints is in the official docs. But it covers the most common ones and the ones that generate the most debate.

Where people get it wrong: the easy recipe and its hidden cost

The most common pattern I see in projects with misconfigured Actuator isn't carelessness — it's accumulation. Someone adds spring-boot-starter-actuator to have /health available for the load balancer. Then someone else adds include: "*" to debug something. Then nobody cleans it up.

The problem with include: "*" isn't just what it exposes today — it's that it automatically exposes any endpoint added in the future, including endpoints from third-party libraries that integrate with Actuator. Spring Security, Micrometer, Spring Cloud, and other frameworks can register their own endpoints under /actuator/. If you have include: "*", they expose themselves.

# What you should have instead of "*"
management:
  endpoints:
    web:
      exposure:
        # Explicit list: you know exactly what's exposed
        include: "health,info,metrics"
        # Everything else is blocked by default
  endpoint:
    health:
      # Show details only to authenticated users
      show-details: when_authorized
  # Separate the management port from the app port
  server:
    port: 8081

That last point — management.server.port — is the most practical change you can make. If Actuator runs on a separate port, you can protect it at the network level (firewall, security group, nginx) without touching application logic. Port 8081 never reaches the public load balancer. Port 8080 does.

Another common mistake: trusting that Spring Security protects Actuator automatically. By default, if you have Spring Security on the classpath, Actuator endpoints are protected by the same rules as the rest of the app — but that's not always enough. Being explicit is worth it:

// SecurityConfig.java
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            // Only /health and /info without authentication
            .requestMatchers("/actuator/health", "/actuator/info").permitAll()
            // The rest of actuator requires ADMIN role
            .requestMatchers("/actuator/**").hasRole("ADMIN")
            .anyRequest().authenticated()
        );
    return http.build();
}

This is more robust than relying on implicit behavior, and it's also living documentation: whoever reads this config understands exactly what's protected and how.

Decision checklist before adding Actuator to a project

Before the first deploy with Actuator enabled, these are the questions worth answering:

On exposure:

[ ] Did you explicitly list which endpoints you want to expose? Or did you use "*"?
[ ] Is Actuator running on a separate port from the application port?
[ ] Is that management port blocked for external traffic?

On authentication:

[ ] Do sensitive endpoints (env, beans, heapdump) require authentication?
[ ] Does health expose details (show-details) without restriction? Do you want that?
[ ] Do you have Spring Security explicitly configured for /actuator/**, or are you relying on default behavior?

On exposed information:

[ ] Did you check what /actuator/env returns in the environment where it's going to run?
[ ] Are there environment variables with credentials showing up in that endpoint?
[ ] Does /actuator/info expose versions, git commits, or metadata you don't want public?

On JMX:

[ ] If you're not using JMX, did you disable it?

# Disable JMX if you're not using it
spring:
  jmx:
    enabled: false

This checklist doesn't guarantee total security — that depends on the full context of the application, the network, and the environment. But it covers the decisions that most frequently get left unmade.

What you can't conclude without your own data

There's something this guide can't do for you: tell you which specific endpoints you actually need in production.

That depends on how you monitor the application. If you're using Prometheus + Grafana, /actuator/prometheus is useful — but if you're using Datadog with the agent installed, you probably don't need to expose it at all. If you have a load balancer doing health checks, you need /actuator/health — but if you're on Kubernetes with liveness/readiness probes pointing to their own endpoint, you can decouple that from Actuator entirely.

Also: the behavior of show-details: when_authorized depends on how Spring Security is configured in that context. Without reviewing the app's actual security configuration, that setting can behave differently than expected.

What you can do today: start with minimal exposure and add endpoints with intention, not with "*". It's easier to add than to remove — especially once you have environments that depend on the current state.

A useful reference if you're evaluating observability integration: the post on Docker healthchecks has an analysis of what availability checks actually measure and what they shouldn't promise — directly applicable if you're deciding whether Actuator /health is enough for your probes or you need something more granular.

FAQ: Spring Boot Actuator and endpoint security

What endpoints does Actuator expose by default via HTTP?
Only /actuator/health is exposed over HTTP in the default configuration. Everything else requires explicit declaration in management.endpoints.web.exposure.include. You can verify this in the official documentation.

Is include: "*" always a problem?
On localhost for development, no. In a shared environment, staging with a semi-public network, or production, yes — because it exposes current and future endpoints without review. The risk isn't just what you're exposing today, it's what gets added automatically when you update dependencies.

Does Spring Security protect Actuator automatically if it's on the classpath?
Partially. Spring Security applies the application's security rules to Actuator, but the concrete behavior depends on how it's configured. The recommended practice is to be explicit with a requestMatchers("/actuator/**") in your security configuration.

Is it worth separating the Actuator port from the application port?
Yes, and it's probably the highest-impact change with the lowest complexity. With management.server.port: 8081, you can protect that port at the network level without touching application code. The public load balancer only sees 8080.

Can /actuator/health expose sensitive information?
Yes, if show-details is set to always. In that mode, the endpoint returns the status of each component — database, cache, external services — with details that can reveal internal URLs or dependency states. show-details: when_authorized is the most conservative setting for exposed environments.

How do I know which endpoints my third-party dependencies registered?
You can check at runtime by calling /actuator (the root endpoint, if it's exposed), which returns the map of all available endpoints. You can also enable it only in development using Spring profiles: @Profile("dev") on the configuration bean, or using spring.profiles.active to load an application-dev.yml with include: "*".

My final take: Actuator as an operational tool, not a default

Actuator is one of the best-designed parts of the Spring Boot ecosystem. The enabled/exposed separation, the Micrometer integration, the native support for custom health indicators — all of that has real operational value.

What has no value is adding it as "it comes in the starter, just in case." That logic works in development. In an environment with a real network, it's a surface area that grows on its own every time you update dependencies.

My practical recommendation: start with include: "health,info", separate the management port from the first deploy, and add endpoints with intention when you have a concrete consumer — a metrics dashboard, an APM tool, a diagnostic script. If you don't know who's consuming the endpoint, you probably don't need to expose it yet.

If you're building a backend with layered security decisions, it might be worth checking out the post on digital identity backend architecture — the "what to expose and with what restrictions" criterion applies in both contexts with similar logic.

Original source:

Spring Boot Actuator — Endpoints: https://docs.spring.io/spring-boot/reference/actuator/endpoints.html

This article was originally published on juanchi.dev

Spring Boot Actuator: qué exponer, qué ocultar y qué mirar antes de agregar endpoints

Juan Torchia — Mon, 01 Jun 2026 12:02:29 +0000

Spring Boot Actuator: qué exponer, qué ocultar y qué mirar antes de agregar endpoints

Estaba revisando la configuración de un backend Spring Boot en un escenario de prueba cuando noté que /actuator/env respondía sin autenticación. Nada de producción, nada crítico — pero la configuración era la default de alguien que agregó la dependencia, vio que /actuator/health funcionaba, y siguió. El endpoint env expone variables de entorno activas, incluyendo cualquier cosa que haya en el contexto de Spring. En un ambiente real, eso puede incluir credenciales interpoladas, URLs internas o flags de feature que no deberían ser públicos.

Mi tesis es esta: Actuator no es malo. Es una herramienta operativa seria, documentada y útil. El error es agregarlo sin decidir qué querés exponer, a quién y con qué restricciones. La mayoría de los tutoriales te dicen cómo habilitarlo. Casi ninguno te explica el costo de habilitarlo mal.

Spring Boot Actuator endpoints seguridad: qué dice la documentación oficial

La documentación oficial de Spring Boot Actuator es explícita en algo que mucha gente ignora: los endpoints tienen dos dimensiones independientes — estar habilitados y estar expuestos.

Un endpoint puede estar habilitado (activo en el contexto de la aplicación) pero no expuesto por HTTP. Por defecto, solo health está expuesto vía HTTP. El resto requiere configuración explícita.

Esto es importante porque el comportamiento por defecto es conservador — pero fácil de sobreescribir con una sola línea:

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: "*"  # Expone TODO — incluyendo lo que no querés exponer

Esa línea aparece en cientos de tutoriales como "para ver todos los endpoints disponibles". Lo cual está bien en localhost. Es un problema si llega a un ambiente compartido o a producción sin revisión.

La doc también distingue entre JMX y HTTP como canales de exposición separados. Por defecto, JMX expone todos los endpoints habilitados, mientras que HTTP es más restrictivo. Si tu aplicación no usa JMX activamente, vale la pena deshabilitar ese canal también.

Los endpoints que merecen atención antes de exponerlos

Endpoint	Qué expone	Riesgo si está público
`/actuator/env`	Variables de entorno del contexto Spring	Alto — puede incluir credenciales
`/actuator/beans`	Todos los beans registrados	Medio — revela arquitectura interna
`/actuator/heapdump`	Dump de memoria JVM	Alto — puede contener datos sensibles en heap
`/actuator/mappings`	Todos los endpoints HTTP de la app	Medio — facilita reconnaissance
`/actuator/loggers`	Configuración de logging activa	Bajo-Medio — permite cambiar niveles en runtime
`/actuator/metrics`	Métricas de la JVM y la app	Bajo — útil internamente, poco valor expuesto
`/actuator/health`	Estado operativo de la app	Bajo si está bien configurado

Esta tabla no es exhaustiva — la lista completa de endpoints built-in está en la documentación oficial. Pero cubre los más frecuentes y los que generan más discusión.

Dónde se equivoca la gente: la receta fácil y su costo oculto

El patrón más común que veo en proyectos con Actuator mal configurado no es descuido — es acumulación. Alguien agrega spring-boot-starter-actuator para tener /health disponible para el load balancer. Después otro agrega include: "*" para debuggear algo. Después nadie limpia.

El problema con include: "*" no es solo lo que expone hoy — es que expone automáticamente cualquier endpoint que se agregue en el futuro, incluyendo endpoints de librerías de terceros que se integran con Actuator. Spring Security, Micrometer, Spring Cloud y otros frameworks pueden registrar sus propios endpoints bajo /actuator/. Si tenés include: "*", se exponen solos.

# Lo que deberías tener en lugar de "*"
management:
  endpoints:
    web:
      exposure:
        # Listado explícito: sabés exactamente qué está expuesto
        include: "health,info,metrics"
        # Todo lo demás queda bloqueado por defecto
  endpoint:
    health:
      # Mostrá detalles solo a usuarios autenticados
      show-details: when_authorized
  # Separar el puerto de management del puerto de la app
  server:
    port: 8081

Ese último punto — management.server.port — es el cambio más práctico que podés hacer. Si Actuator corre en un puerto separado, podés protegerlo a nivel de red (firewall, security group, nginx) sin tocar la lógica de la aplicación. El puerto 8081 nunca llega al load balancer público. El 8080 sí.

Otro error común: confiar en que Spring Security protege Actuator automáticamente. Por defecto, si tenés Spring Security en el classpath, los endpoints de Actuator quedan protegidos con las mismas reglas del resto de la app — pero eso no siempre es suficiente. Vale la pena ser explícito:

// SecurityConfig.java
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            // Solo /health y /info sin autenticación
            .requestMatchers("/actuator/health", "/actuator/info").permitAll()
            // El resto de actuator requiere rol ADMIN
            .requestMatchers("/actuator/**").hasRole("ADMIN")
            .anyRequest().authenticated()
        );
    return http.build();
}

Esto es más robusto que depender del comportamiento implícito, y además es documentación viva: quien lea la config entiende exactamente qué está protegido y cómo.

Checklist de decisión antes de agregar Actuator a un proyecto

Antes de hacer el primer deploy con Actuator habilitado, estas son las preguntas que vale la pena responder:

Sobre exposición:

[ ] ¿Listaste explícitamente qué endpoints querés exponer? ¿O usaste "*"?
[ ] ¿Actuator corre en un puerto separado del puerto de la aplicación?
[ ] ¿Ese puerto de management está bloqueado para tráfico externo?

Sobre autenticación:

[ ] ¿Los endpoints sensibles (env, beans, heapdump) requieren autenticación?
[ ] ¿health expone detalles (show-details) sin restricción? ¿Querés eso?
[ ] ¿Tenés Spring Security configurado explícitamente para /actuator/**, o dependés del comportamiento por defecto?

Sobre información expuesta:

[ ] ¿Revisaste qué devuelve /actuator/env en el ambiente donde va a correr?
[ ] ¿Hay variables de entorno con credenciales que aparecen en ese endpoint?
[ ] ¿/actuator/info expone versiones, git commit o metadata que no querés pública?

Sobre JMX:

[ ] Si no usás JMX, ¿lo deshabilitaste?

# Deshabilitar JMX si no lo usás
spring:
  jmx:
    enabled: false

Este checklist no garantiza seguridad total — eso depende del contexto completo de la aplicación, la red y el ambiente. Pero cubre las decisiones que más frecuentemente quedan sin tomar.

Qué no podés concluir sin datos propios

Hay algo que esta guía no puede hacer por vos: decirte qué endpoints específicamente necesitás en producción.

Eso depende de cómo monitoreas la aplicación. Si usás Prometheus + Grafana, /actuator/prometheus es útil — pero si usás Datadog con el agente instalado, probablemente no necesitás exponerlo en absoluto. Si tenés un load balancer que hace health checks, necesitás /actuator/health — pero si usás Kubernetes con liveness/readiness probes apuntando a un endpoint propio, podés separar eso de Actuator completamente.

También: el comportamiento de show-details: when_authorized depende de cómo Spring Security está configurado en ese contexto. Sin revisar la configuración real de seguridad de la app, ese setting puede comportarse diferente a lo esperado.

Lo que sí podés hacer hoy: arrancar con exposición mínima y agregar endpoints con intención, no con "*". Es más fácil agregar que quitar — especialmente si ya hay ambientes que dependen del estado actual.

Una referencia útil si estás evaluando la integración con observabilidad: en el post sobre Docker healthchecks hay un análisis de qué miden realmente los checks de disponibilidad y qué no deberían prometer — aplica directamente si estás decidiendo si Actuator /health es suficiente para tus probes o necesitás algo más granular.

FAQ: Spring Boot Actuator y seguridad de endpoints

¿Qué endpoints expone Actuator por defecto vía HTTP?
Solo /actuator/health está expuesto por HTTP en la configuración por defecto. El resto requiere declaración explícita en management.endpoints.web.exposure.include. Podés verificarlo en la documentación oficial.

¿include: "*" es siempre un problema?
En localhost para desarrollo, no. En un ambiente compartido, staging con red semipública o producción, sí — porque expone endpoints actuales y futuros sin revisión. El riesgo no es solo lo que exponés hoy, sino lo que se agrega automáticamente cuando actualizás dependencias.

¿Spring Security protege Actuator automáticamente si está en el classpath?
Parcialmente. Spring Security aplica las reglas de seguridad de la aplicación a Actuator, pero el comportamiento concreto depende de cómo esté configurado. La práctica recomendada es ser explícito con un requestMatchers("/actuator/**") en la configuración de seguridad.

¿Vale la pena separar el puerto de Actuator del puerto de la aplicación?
Sí, y es probablemente el cambio de mayor impacto con menor complejidad. Con management.server.port: 8081, podés proteger ese puerto a nivel de red sin tocar el código de la aplicación. El load balancer público solo ve el 8080.

¿/actuator/health puede exponer información sensible?
Sí, si show-details está en always. En ese modo, el endpoint devuelve el estado de cada componente — base de datos, cache, servicios externos — con detalles que pueden revelar URLs internas o estados de dependencias. show-details: when_authorized es el setting más conservador para ambientes expuestos.

¿Cómo sé qué endpoints registraron mis dependencias de terceros?
Podés consultarlo en runtime con una llamada a /actuator (el endpoint raíz, si está expuesto), que devuelve el mapa de todos los endpoints disponibles. También podés habilitarlo solo en desarrollo con profiles de Spring: @Profile("dev") en el bean de configuración o usando spring.profiles.active para cargar un application-dev.yml con include: "*".

Mi postura final: Actuator como herramienta operativa, no como default

Actuator es una de las partes mejor diseñadas del ecosistema Spring Boot. La separación entre habilitado/expuesto, la integración con Micrometer, el soporte nativo para health indicators personalizados — todo eso tiene valor operativo real.

Lo que no tiene valor es agregarlo como "viene en el starter, por las dudas". Esa lógica funciona en desarrollo. En un ambiente con red real, es una superficie que crece sola cada vez que actualizás dependencias.

Mi recomendación práctica: empezá con include: "health,info", separé el puerto de management desde el primer deploy, y agregá endpoints con intención cuando tengas un consumidor concreto — un dashboard de métricas, una herramienta de APM, un script de diagnóstico. Si no sabés quién consume el endpoint, probablemente no necesitás exponerlo todavía.

Si estás construyendo un backend con decisiones de seguridad en capas, puede ser útil revisar también el post sobre arquitectura backend de identidad digital — el criterio de "qué exponer y con qué restricciones" aplica en ambos contextos con lógica similar.

Fuente original:

Spring Boot Actuator — Endpoints: https://docs.spring.io/spring-boot/reference/actuator/endpoints.html

Este artículo fue publicado originalmente en juanchi.dev

DEV Community: Juan Torchia

Rate limiting in web apps: what to protect before picking a library

Rate limiting in web apps: what to protect before picking a library

What rate limiting in Next.js actually is — and what it isn't

The classic mistake: copying middleware before defining the asset

The decision matrix: four questions before writing a single line

1. What asset are you protecting?

2. What abuse are you expecting?

3. What does a false positive cost you?

4. How do you observe that it's working?

Where people get it wrong: three patterns that look right but aren't

Limits of this guide: what you can't conclude without your own data

FAQ: rate limiting in Next.js web applications

The library doesn't decide the policy. You do.

Rate limiting en aplicaciones web: qué proteger antes de elegir una librería

Rate limiting en aplicaciones web: qué proteger antes de elegir una librería

Qué es rate limiting en aplicaciones web con Next.js — y qué no es

El error clásico: copiar el middleware antes de definir el activo

La matriz de decisión: cuatro preguntas antes de escribir una línea

1. ¿Qué activo protegés?

2. ¿Qué abuso esperás?

3. ¿Cuánto te cuesta un falso positivo?

4. ¿Cómo observás que está funcionando?

Dónde se equivoca la gente: tres patrones que parecen bien pero no lo son

Límites de esta guía: qué no podés concluir sin datos propios

FAQ: rate limiting en aplicaciones web con Next.js

Cierre: la librería no decide la política, vos sí

Next.js 16 Middleware: authorization patterns that scale and the ones that cause race conditions

Next.js 16 Middleware: authorization patterns that scale and the ones that cause race conditions

The real problem: edge runtime is not Node.js

The 4 patterns: tradeoff analysis

Pattern 1 — Full token validation in middleware

Pattern 2 — Role-based redirects in middleware

Pattern 3 — API route protection only in middleware

Pattern 4 — Middleware composition

The gotchas nobody documents well

The pattern I'd adopt in a new system

What you can't conclude without your own experiment

FAQ — Common questions about Next.js 16 Middleware and authorization

The middleware is not your primary authorization layer

Next.js 16 Middleware: patrones de autorización que escalan y los que generan race conditions

Next.js 16 Middleware: patrones de autorización que escalan y los que generan race conditions

El problema real: edge runtime no es Node.js

Los 4 patrones: análisis de tradeoffs

Patrón 1 — Validación de token completo en middleware

Patrón 2 — Role-based redirects en middleware

Patrón 3 — API route protection solo en middleware

Patrón 4 — Composición de middlewares

Los gotchas que nadie documenta bien

El patrón que adoptaría en un sistema nuevo

Lo que no podés concluir sin experimento propio

FAQ — Preguntas frecuentes sobre Next.js 16 Middleware y autorización

Conclusión: el middleware no es tu capa de autorización principal

Prisma 5 Prisma 6: The Breaking Changes I Hit in My Real Schema and How I Fixed Them Without Breaking Production

Prisma 5 → Prisma 6: The Breaking Changes I Hit in My Real Schema and How I Fixed Them Without Breaking Production

Why Prisma 6 Matters (and What the Official Announcement Actually Says)

Change 1: selectRelationCount Is No Longer Opt-In — How You Count Relations Changed

Change 2: The Behavior of undefined in Relational Queries Changed

Change 3: The Generated Client Was Reorganized and Direct Type Imports Can Break

Common Migration Mistakes — The Gotchas That Keep Showing Up

Prisma 5 → 6 Migration Checklist

FAQ — Prisma 6 Migration Breaking Changes

The Upgrade Is Worth It, But You Have to Earn It

Prisma 5 Prisma 6: los breaking changes que encontré en mi schema real y cómo los resolví sin romper producción

Prisma 5 → Prisma 6: los breaking changes que encontré en mi schema real y cómo los resolví sin romper producción

Por qué Prisma 6 importa (y qué dice el anuncio oficial)

Cambio 1: selectRelationCount ya no es opt-in — cambió la forma de contar relaciones

Cambio 2: el comportamiento de undefined en queries relacionales cambió

Cambio 3: el cliente generado cambió y los imports directos de tipos pueden romperse

Errores comunes en la migración — los gotchas que más aparecen

Checklist de migración Prisma 5 → 6

FAQ — Prisma 6 migration breaking changes

Conclusión: vale el upgrade, pero hay que ganárselo

tsgo: what changes in the TypeScript compiler rewritten in Go and what it means for real projects

tsgo: what changes in the TypeScript compiler rewritten in Go and what it means for real projects

tsgo typescript compiler go: what it is and where it came from

What limitations the beta has today

The common mistakes when evaluating tsgo

Decision matrix: when to explore tsgo today

What you can't conclude without your own experiment

Change 1: `selectRelationCount` Is No Longer Opt-In — How You Count Relations Changed

Change 2: The Behavior of `undefined` in Relational Queries Changed

Cambio 1: `selectRelationCount` ya no es opt-in — cambió la forma de contar relaciones

Cambio 2: el comportamiento de `undefined` en queries relacionales cambió