Fastify o Express: cómo elegir el marco HTTP en 2026.

Express sigue siendo el camino más corto para un prototipo y para integrar middleware clásico —funciones que procesan la petición en cadena: auth, logs, parseo del body—. Fastify gana cuando el contrato de la API se declara con esquemas JSON, el encapsulado de plugins importa y cada milisegundo de serialización cuenta.

En 2026 ambos conviven con el mismo runtime Node. El criterio de Ambigram es simple: si el producto es un panel interno o un BFF —Backend For Frontend, API pequeña que adapta datos solo para tu web— con pocas rutas, Express (o incluso el http nativo con un router mínimo) basta.

Si es una API pública con validación, logs estructurados y muchas rutas, Fastify reduce fricción. En otras palabras: Express es la furgoneta que arranca en el primer intento; Fastify es el furgón con cajas etiquetadas cuando mueves cien paquetes distintos cada día.

Lo que no negociamos es la capa de autenticación, límites de cuerpo y observabilidad —métricas y trazas para saber qué falla en producción—. El framework no es la arquitectura; es el enchufe. Elegirlo mal se nota a los seis meses, no en el primer hola mundo.

Los agentes de código suelen proponer Express por defecto porque aparece en más ejemplos. Un AGENTS.md que dice «usamos Fastify con esquemas en este repo» evita migraciones fantasmas a mitad del sprint. Piénsalo como indicar en el taller qué llave usa cada tornillo.

Fastify o Express en 2026 no es una guerra de benchmarks en Twitter. Es una decisión de mantenimiento: quién lee el código en tres años, qué tan estricta debe ser la validación y si la API crecerá más de lo que el diagrama inicial prometió.