Desarrollo de aplicaciones Next.js

La mayoría de los proyectos Next.js fracasan despacio. La primera versión sale a tiempo y se ve bien. Después el bundle crece, use client se propaga hacia arriba por el árbol, cada página se vuelve dinámica en silencio, y dieciocho meses más tarde el equipo discute sobre reescribirlo todo.

Ese deterioro es arquitectónico, y se puede evitar. Ninguna de las decisiones que lo causan es difícil en el momento en que se toma: simplemente se toman sin que nadie note que había una decisión que tomar.

Qué construimos

Aceptamos aplicaciones nuevas donde la estrategia de renderizado importa de verdad: frontends de comercio, superficies de producto SaaS, plataformas de documentación, sitios de marketing multirregión y sistemas de contenido que deben servir miles de rutas sin que el build tarde una hora.

Donde un proyecto tiene forma propia, tiene página propia: comercio tiene un catálogo y un carrito con tiempos de caché distintos en la misma pantalla, SaaS tiene superficies autenticadas donde casi nada puede ser estático, y enterprise añade SSO, residencia de datos y compras a todo lo anterior. Esta página es el trabajo que comparten.

Cómo se decide la arquitectura

La estrategia de renderizado se elige por ruta, no por proyecto, y se deja por escrito antes de empezar a implementar:

• Estático para todo aquello cuyo contenido cambia al publicar y no en cada petición: páginas de marketing, documentación, el blog.
• Revalidación incremental para contenido con su propio ritmo, con etiquetas de revalidación conectadas al webhook del CMS en lugar de a un TTL fijo.
• Dinámico y en streaming para superficies realmente por petición -paneles, carritos, cualquier cosa tras autenticación- con los límites de Suspense trazados para que el armazón pinte de inmediato y los datos lentos lleguen después.

La frontera cliente/servidor se trata como un artefacto de diseño. Los Server Components son el valor por defecto; use client es una decisión deliberada y revisada que se detiene en la hoja interactiva más pequeña en lugar de propagarse hasta un layout.

Eso suena a preferencia de estilo hasta que le pones precio. Una directiva use client en un layout envía ese layout, sus hijos y sus dependencias a cada visitante en cada ruta por debajo. La misma directiva en el único desplegable que necesita estado envía unos pocos kilobytes. El código es idéntico; la ubicación es todo el coste.

La capa de datos se decide al mismo tiempo

La estrategia de renderizado no significa nada sin saber de dónde vienen los datos y cuán desactualizados pueden estar. Así que ambas se especifican juntas, por superficie: el sistema de origen, la forma que toman al cruzar a la aplicación, quién puede leerlos y qué los invalida.

Los tipos recorren todo el camino - desde el cliente de la API o la consulta a la base de datos hasta el componente que muestra el valor - porque una frontera tipada es lo que convierte un cambio de backend en un build fallido en lugar de un hueco en blanco en producción. Cuando hay un CMS de por medio, esa integración forma parte de este trabajo y no es una fase añadida después del front end: ese orden es precisamente el que produce un modelo de contenido que nadie sabe editar.

Cómo se desarrolla un encargo

Por fases, cada una terminando con algo desplegado que puedes usar.

1. Alcance y arquitectura. Inventario de rutas, decisión de renderizado por ruta, fuentes de datos, lista de integraciones y las reglas de frontera. Esta fase decide el coste de todas las siguientes, y produce un documento, no una presentación.
2. La espina dorsal. Enrutado, layouts, capa de datos, autenticación si la hay, las primitivas de componentes, y CI con el presupuesto ya aplicado. Nada visual está terminado; todo lo estructural sí.
3. Superficies, por orden de prioridad. Construidas contra las convenciones fijadas en la fase dos, revisadas por tus ingenieros si los tienes, desplegadas al final de cada iteración en lugar de acumuladas para un lanzamiento.
4. Endurecimiento y traspaso. Rendimiento medido contra el presupuesto en lugar de contra una puntuación, accesibilidad revisada a nivel de componente, la nota de arquitectura escrita, y un recorrido por superficie con quien la hereda.

Trabajamos en tu repositorio, en tu gestor de incidencias, en tu proceso de revisión. Un proyecto que vive en nuestras herramientas hasta el día del lanzamiento es un proyecto que tu equipo conoce por primera vez cuando ya es tarde para discrepar de él.

Qué mueve la estimación

El framework no. Lo que decide cuánto tarda un proyecto en Next.js es lo mismo que decide cuánto tarda cualquier proyecto, y saber cuáles de estos puntos te afectan es más útil que una tarifa diaria:

• Con cuántos sistemas tiene que hablar. Un CMS es una semana. Un CMS, un ERP, una pasarela de pago y un endpoint SOAP heredado que nadie ha documentado es otro proyecto.
• Si el modelo de contenido existe. Construir contra un modelo que todavía se está discutiendo es la forma más fiable de construir la misma pantalla tres veces.
• Cuánta superficie está autenticada. Las superficies autenticadas no se pueden servir estáticamente, así que cuestan más de acelerar y más de probar.
• Si existe un sistema de diseño o se está inventando sobre la marcha. Ambas cosas están bien; no son la misma cantidad de trabajo.
• Cuántos idiomas, y si son traducciones reales o la misma página con una bandera. El enrutado internacional cambia la estructura de URLs, y esa no es una decisión tardía.

Qué se entrega con ello

Cada proyecto sale con una capa de datos tipada, una biblioteca de componentes documentada en el repositorio, CI que ejecuta typecheck, lint y un presupuesto de Lighthouse en cada pull request, y una nota de arquitectura que explica por qué cada ruta renderiza como renderiza.

Ese último documento es el que importa en el segundo año. Es la diferencia entre una base de código que tu equipo amplía y una que tu equipo sustituye.

Cuándo este no es el encargo adecuado

Si tienes ingenieros capaces y la carencia es arquitectónica y no de capacidad, lo que quieres es desarrollo con App Router: nosotros fijamos la frontera, el modelo de caché y la estructura de rutas, tu equipo construye encima, y el conocimiento se queda en tu casa.

Si ya existe una aplicación y el problema es que se ha vuelto difícil de cambiar, eso es migración y rescate, y empieza leyendo antes que escribiendo.

Si todavía no sabes cuál de las dos es tu caso, una auditoría lo responde en dos semanas y cuesta una fracción de equivocarse.