Arquitectura de aplicaciones
Desarrollo con App Router de Next.js
Arquitectura de App Router para equipos con ingenieros propios - la frontera servidor/cliente, el modelo de caché y la organización de rutas decididos a propósito, con tu gente en los pull requests.
Este es el texto si tienes ingenieros y el problema no es capacidad. Estás construyendo sobre el App Router, el equipo es capaz, y las decisiones de arquitectura las toma quien tocó el fichero por última vez.
Si lo que quieres es un producto construido de punta a punta, eso es desarrollo de aplicaciones y es otro encargo: allí la entrega la sostenemos nosotros. Aquí la sostienes tú, y nosotros nos aseguramos de que el modelo de debajo sea el correcto mientras tu equipo construye encima.
Las cuatro decisiones que salen caras después
Dónde está la frontera de cliente. use client va derivando hacia la raíz
un commit razonable cada vez: un desplegable necesita estado, la cabecera se
lleva la directiva, y dieciocho meses después el layout es un componente de
cliente y cada ruta envía el árbol entero. Fijamos la frontera a propósito y la
convertimos en regla de revisión, que vale más que cualquier analizador de
bundles porque caza la deriva cuando empieza.
Qué guarda cada caché. Hay cuatro, con cuatro vidas, y "cambiamos los datos y la página no se actualizó" casi siempre es confundirlas y no un bug. Una convención de nombres de etiquetas que tu equipo aplique de verdad es el entregable aquí.
Qué puede volver dinámica una ruta. Una llamada a cookies() en un
componente compartido vuelve dinámica cada ruta por debajo y te cuesta el CDN.
Saber qué lecturas hacen eso, y mantenerlas detrás de una frontera, es la
diferencia entre un sitio que sirve desde el edge y uno que renderiza por
visitante.
Cómo se organizan las rutas. Los route groups, las parallel routes y las intercepting routes resuelven problemas reales y son también la forma más fácil de construir algo por lo que nadie sabe navegar. Las usamos donde se lo ganan.
Cómo funciona
No una presentación. Trabajamos en tu repositorio durante un periodo cerrado -normalmente de cuatro a ocho semanas- y el trabajo son pull requests que revisan tus ingenieros, más las convenciones escritas donde está el código.
La forma habitual:
- Una lectura de lo que hay. El modo de render de cada ruta, la frontera, las cachés en uso, el First Load JS por ruta. Dos semanas, y el mismo documento que produce una auditoría.
- Las decisiones, tomadas y escritas. Regla de frontera, convención de etiquetas de caché, estructura de rutas, y qué puede ser dinámico.
- Aplicado a las rutas que importan, con tu equipo en las revisiones. No a todas: a las suficientes para que el patrón sea inequívoco y puedan terminarlo.
- Un presupuesto de rendimiento en CI, para que las decisiones sobrevivan al encargo.
Por qué es un servicio aparte
Porque la alternativa es un equipo aprendiendo el modelo de render a base de incidencias en producción, que es la forma más cara de aprenderlo y la más común.
Casi nada de lo que sale mal en aplicaciones con App Router es dificultad. Es que los valores por defecto son lo bastante buenos como para publicar con ellos, así que nadie decide, y las decisiones se toman por accidente. La explicación completa del modelo es pública - el modelo de renderizado del App Router, explicado como toca
- y esto es eso, aplicado a tu código con tus ingenieros.