Por qué construimos todo sobre Next.js y el edge

Hemos probado muchos stacks. Tras construir más de 40 sitios y aplicaciones en producción, hemos convergido en Next.js desplegado en el edge como opción por defecto. Aquí está el razonamiento, incluidas las contrapartidas.

Por qué Next.js

Next.js le da la posibilidad de elegir la estrategia de renderizado correcta por ruta —generación estática, renderizado en servidor o renderizado en cliente— sin cambiar de framework.

En un sitio de marketing, la mayoría de las páginas son estáticas. El blog se genera estáticamente. El endpoint del formulario de contacto se renderiza en servidor. La demo interactiva se renderiza en cliente. Un mismo framework lo cubre todo.

El App Router (introducido en la v13, maduro desde la v15) trae los React Server Components, lo que significa que puede obtener datos en el servidor y enviar cero JavaScript al cliente para componentes que no necesitan interactividad. Una página con mucho contenido que antes enviaba 200 KB de JS ahora envía 15 KB.

Por qué el edge

Los servidores tradicionales se ejecutan en una sola región. Un usuario en Singapur llegando a un servidor en us-east-1 añade 200-300 ms de latencia de red a cada petición antes incluso de que el servidor procese nada.

Los runtimes edge —Vercel Edge Functions, Cloudflare Workers— ejecutan su código en más de 30 ubicaciones a nivel global. El servidor siempre está cerca del usuario. TTFB consistentemente por debajo de 50 ms en todo el mundo.

La contrapartida: los runtimes edge están limitados. No hay acceso al sistema de archivos, las APIs de Node.js son limitadas, los límites de memoria son menores. Esto obliga a una disciplina arquitectónica: funciones sin estado, datos obtenidos desde APIs o bases de datos cacheadas en el edge.

El stack completo

• Framework: Next.js (App Router)
• Estilos: Tailwind CSS v4
• Base de datos: Postgres en Neon (serverless, compatible con edge) o Supabase
• Autenticación: Clerk o next-auth según la complejidad
• Correo: Resend
• Pagos: Stripe
• CMS: ficheros MDX en el repositorio para sitios con mucho contenido; Sanity para contenido editable por el cliente
• Despliegue: Vercel

Lo que no usamos

No usamos renderizado en cliente para páginas que no lo requieren. No usamos APIs REST cuando una server action o una obtención de datos con RSC es más sencilla. No añadimos un framework de backend cuando los route handlers de Next.js bastan.

La complejidad se compone. Cada servicio adicional es otra cosa que puede fallar, otra capa de autenticación, otro pipeline de despliegue. El stack correcto es el más simple que cubre los requisitos.

Construya para los requisitos que tiene. Añada complejidad solo cuando se haya quedado pequeña la solución más simple.