Cómo utilizo Next.js en mi trabajo

Next.js es mi opción predeterminada para productos web, y no porque esté de moda. Una sola base de código TypeScript cubre lo que antes eran tres proyectos: el sitio de marketing que debe posicionarse en buscadores, la aplicación tras el inicio de sesión y la capa API ligera que los conecta. Este sitio es un ejemplo pequeño: rutas localizadas, metadatos generados, sitemap, imágenes Open Graph y una ruta llms.txt, todo desde el mismo proyecto con App Router.

Empiezo por el servidor. Las páginas y los layouts son Server Components de forma predeterminada: obtienen los datos cerca de la base de datos, envían HTML en vez de un bundle de JavaScript y mantienen los secretos en el servidor. «use client» va solo en las hojas del árbol que necesitan estado, efectos o API del navegador: un formulario, un desplegable, un mapa. Cuando el árbol entero empieza con «use client», suelen llegar un bundle pesado y toda una clase de errores.

Elegir el modo de renderizado es una decisión de producto, no una preferencia técnica. Generación estática para páginas que cambian al desplegar. ISR o revalidación por etiquetas para catálogos, listados y blogs que cambian durante el día: revalidateTag después de escribir, no un temporizador que nadie entiende. Renderizado dinámico con streaming de Suspense para paneles y datos personales: primero aparece la estructura y después llega la información más lenta. Anoto por qué cada ruta es estática o dinámica; esa línea ahorra una semana de «¿por qué el precio está desactualizado?».

Para las mutaciones uso Server Actions en formularios propios de la página y Route Handlers cuando un servicio externo debe llamar a la aplicación: webhooks de un proveedor de pagos o Telegram, un cliente móvil o una tarea cron. En cualquier caso, Zod valida los datos de entrada en el servidor, allí se comprueba la autenticación y el cliente nunca decide nada sobre dinero ni permisos. En productos grandes, Next.js sigue siendo el frontend y el BFF, mientras que el dominio principal vive en un servicio NestJS o Node.js con su propia base de datos.

El rendimiento y el SEO forman parte de la definición de terminado. Uso next/image con tamaños reales, next/font para evitar saltos de diseño, generateMetadata y datos estructurados en cada página pública, importaciones dinámicas para widgets pesados y compruebo Core Web Vitals en un móvil de gama media, no en un MacBook. Despliego en Vercel si el equipo quiere evitar las operaciones, o con una compilación standalone en Docker sobre AWS o un VPS cuando importan el coste, la residencia de los datos o las tareas de larga duración.

Me niego a poner «use client» en el layout raíz, pedir los mismos datos desde cinco componentes sin pensar en la caché, esconder lógica de negocio en middleware o actualizar a una versión principal un viernes sin leer los codemods. Si tu aplicación Next.js parece lenta o frágil, envíame el repositorio y las dos páginas más lentas. Te diré qué movería al servidor, qué pondría en caché y qué eliminaría.