Next.js 15: Guía Full-Stack con App Router, ISR y Server Actions
Next.js 15 consolida su posición como el framework full-stack dominante del ecosistema React. Con App Router madurado, Server Actions estables, ISR mejorado y soporte nativo de Edge Runtime, es la plataforma más completa para construir desde una landing page hasta un SaaS con miles de usuarios. En esta guía cubrimos las 6 áreas que más impactan tu arquitectura, con patrones probados, ejemplos de código y una guía de migración paso a paso. Este post asume familiaridad con las features clave de React 19 (Server Components, Actions, use()). Si necesitás un repaso del lado React puro antes de bajar al framework, empezá por React 19: Guía Práctica de Server Components, Actions y Performance.
App Router avanzado: layouts, loading y error boundaries
El App Router de Next.js 15 reemplaza completamente al Pages Router como la forma recomendada de estructurar aplicaciones. Su modelo basado en el filesystem usa convenciones de archivos: layout.js (UI compartida entre rutas hijas), page.js (UI única de la ruta), loading.js (skeleton automático con Suspense), error.js (error boundary por segmento) y not-found.js (404 personalizado). Los layouts son persistentes — no se re-renderizan al navegar entre rutas hijas, lo que elimina flickers y mantiene estado (scroll position, formularios parciales). Los grupos de rutas (route groups con paréntesis) permiten organizar sin afectar la URL. Los parallel routes y intercepting routes habilitan patrones como modales que son URLs completas. Si tu equipo está evaluando Next.js 15 para una migración o un nuevo proyecto, en FranMotion arquitectamos productos full-stack con App Router, ISR y Server Actions — desde landing pages hasta SaaS con miles de usuarios.
- layout.js: UI persistente entre rutas hijas — no se re-renderiza al navegar.
- loading.js: skeleton automático con Suspense — loading state sin código extra.
- error.js: error boundary por segmento — errores aislados, no crashes globales.
- Route groups: (marketing), (dashboard) — organiza sin afectar URLs.
- Parallel routes: @modal, @sidebar — renderiza múltiples páginas en la misma URL.
Server Actions y Mutations sin API Routes
Las Server Actions eliminan la necesidad de crear API routes para la mayoría de las mutaciones. Defines una función async con "use server", la pasas como action de un form o la invocas desde un event handler, y Next.js se encarga de la serialización, el envío y la revalidación de caché. El progressive enhancement funciona out-of-the-box: los formularios con Server Actions envían datos incluso sin JavaScript habilitado. useOptimistic permite actualizar la UI inmediatamente mientras el servidor procesa. Para validación, la combinación con Zod en el servidor garantiza type-safety completa. El patrón recomendado: un archivo actions.js por feature, con funciones que validan input, mutan la DB via Prisma, y revalidan la caché con revalidatePath o revalidateTag.
- Form actions: <form action={createPost}> — sin fetch, sin useState, sin loading manual.
- Optimistic updates: useOptimistic muestra el resultado esperado antes de la confirmación.
- Progressive enhancement: forms funcionan sin JS — fundamental para accesibilidad.
- Revalidation: revalidatePath("/blog") o revalidateTag("posts") después de mutar.
"Server Actions eliminan la capa de API para el 80% de las mutaciones. Menos código, menos bugs, mejor DX."
ISR y estrategias de caching
Incremental Static Regeneration (ISR) permite tener lo mejor de ambos mundos: la velocidad de páginas estáticas con la frescura de datos dinámicos. Next.js 15 ofrece 4 estrategias de caching: time-based (revalida cada N segundos), on-demand (revalida cuando los datos cambian via revalidateTag), route segment config (exporta revalidate por segmento de ruta) y fetch cache (control granular por request). La recomendación para la mayoría de las apps: páginas de contenido con revalidación time-based cada 60 segundos, páginas de resultado de búsqueda con on-demand revalidation, y datos de usuario siempre dinámicos (no-store). El Partial Prerendering (PPR) en Next.js 15 combina shell estático con slots dinámicos — el holy grail del rendering.
- Time-based: revalidate = 60 — la página se regenera cada 60 segundos como máximo.
- On-demand: revalidateTag("products") — invalida cuando la data cambia, no antes.
- Route segment: export const revalidate = 3600 — configuración por archivo de ruta.
- Partial Prerendering (PPR): shell estático + slots dinámicos — lo mejor de SSG + SSR.
Edge Runtime y Middleware
El Edge Runtime ejecuta código en el edge network (CDN) en lugar del servidor de origen, reduciendo la latencia a <50ms para usuarios globales. Next.js 15 permite configurar qué rutas usan Edge y cuáles Node.js según la necesidad. El Middleware (middleware.js en la raíz) intercepta requests antes de que lleguen a la ruta y es ideal para: geolocalización (servir contenido según país), autenticación (redirect a login si no hay sesión), A/B testing (asignar variante sin flash) y rate limiting. El Edge Runtime tiene restricciones: no soporta todas las APIs de Node.js (no fs, no net), pero soporta fetch, crypto, y la mayoría de las librerías modernas.
- Geolocalización: detecta país/región en el edge y sirve contenido localizado sin latencia.
- Auth en el edge: verifica JWT o session cookie antes de que el request llegue al servidor.
- A/B testing: asigna variante en el middleware — sin flash of content, sin client-side redirect.
Deployment optimizado en Vercel (y alternativas)
Vercel es el deployment más optimizado para Next.js (son los mismos creadores), pero no es la única opción. En Vercel, el deploy es zero-config: push a git y el preview deployment está listo en <30 segundos. Las configuraciones clave para producción: configurar headers de seguridad (CSP, HSTS), activar Image Optimization con el loader de Vercel, configurar redirects para SEO, y habilitar Speed Insights para monitorear Core Web Vitals en usuarios reales. Para alternativas: Railway y Render soportan Next.js con Docker, AWS Amplify tiene soporte nativo, y puedes self-host con output: standalone + Docker. La elección depende del presupuesto y los requisitos de compliance. Para una visión completa de cómo elegir infraestructura en contexto SaaS, nuestra guía de arquitectura SaaS cubre el análisis de costos vs. escala. Cuando evaluamos Next.js 15 para arquitecturas full-stack frente a alternativas (Remix, Astro, SvelteKit), el peso del ecosistema React y la integración nativa con Vercel siguen siendo el diferenciador práctico para proyectos que necesitan SSR + ISR + edge sin armar la plomería desde cero. El trade-off real está en el lock-in implícito a Vercel para algunas features (Edge Middleware con full performance, image optimization), aunque las alternativas de hosting (Cloudflare, AWS Amplify) cubren cada vez mejor. Nuestra recomendación: si el equipo ya conoce React y necesita full-stack rápido, Next.js sigue siendo la opción default.
- Vercel: zero-config, preview deploys, Edge Functions — la opción más integrada.
- Railway/Render: Docker-based, más control, mejor para equipos con DevOps propio.
- AWS Amplify: soporte nativo Next.js, integración con servicios AWS.
- Self-host: output: "standalone" + Docker — máximo control, más mantenimiento.
Migración gradual desde Pages Router
La buena noticia: Pages Router y App Router coexisten en el mismo proyecto. Puedes migrar ruta por ruta sin reescribir toda la app. El proceso recomendado: primero, crea app/ directory al lado de pages/ — Next.js prioriza app/ para rutas duplicadas. Segundo, migra rutas estáticas simples (about, contact, terms) para familiarizarte con las convenciones. Tercero, migra rutas con data fetching: getServerSideProps se convierte en Server Components con fetch directo, getStaticProps se convierte en Server Components con revalidate. Cuarto, migra rutas con mutaciones: API routes de POST/PUT/DELETE se convierten en Server Actions. Quinto, migra layouts compartidos (header, footer, sidebar) a layout.js raíz. Sexto, elimina pages/ cuando todas las rutas estén en app/. El timeline típico para una app de 20-50 rutas: 4-6 sprints.
- Paso 1: crear app/ al lado de pages/ — coexisten sin conflicto.
- Paso 2: migrar rutas estáticas simples (about, contact, terms).
- Paso 3: migrar data fetching: getServerSideProps → Server Components.
- Paso 4: migrar mutations: API routes POST/PUT → Server Actions.
- Paso 5: migrar layouts compartidos a layout.js raíz.
- Paso 6: eliminar pages/ y limpiar configuración legacy.
"No migres todo de golpe. Coexiste Pages y App Router, migra ruta por ruta, y valida en cada paso."
Checklist accionable
- Define el modelo de rendering por ruta antes de implementar (static, dynamic, ISR).
- Usa Server Actions para mutations — elimina API routes innecesarias.
- Configura caching strategy: time-based para contenido, on-demand para datos transaccionales.
- Implementa Middleware para auth, geo y A/B testing en el edge.
- Configura headers de seguridad (CSP, HSTS, X-Frame-Options) en next.config.js.
- Activa Speed Insights para monitorear Core Web Vitals en usuarios reales.
- Migra desde Pages Router gradualmente: ruta por ruta, no big-bang.
- Mide Lighthouse antes y después de cada cambio de rendering strategy.