Trade-offs de arquitectura: decidir con criterio
SSG contra SSR, bundle contra no-bundle, monorepo contra polyrepo: las grandes decisiones de arquitectura no tienen ganador absoluto, solo compromisos que encajan mejor o peor con tu restricción real. Esta lección enseña a decidir con criterio en vez de con dogma, dando el eje que gobierna cada disyuntiva y el marco para elegir sin arrepentirse.
Las decisiones grandes de arquitectura no tienen respuesta universal. SSG contra SSR, empaquetar contra no empaquetar, monorepo contra polyrepo: en cada disyuntiva, el ingeniero novato busca al ganador absoluto y el experimentado busca el eje que la gobierna, porque sabe que la respuesta correcta depende de una restricción que cambia con el producto. Este track te dio las piezas; esta lección te da el criterio para combinarlas. Decidir con criterio no es tener opiniones fuertes sobre herramientas: es saber qué variable pesa en cada compromiso y elegir la esquina que encaja con ella, aceptando conscientemente lo que renuncias. Un arquitecto no evita los trade-offs; los nombra y los elige.
- Reconocer que las grandes decisiones de arquitectura son compromisos, no verdades.
- Identificar el eje que gobierna cada disyuntiva: SSG/SSR, bundle/no-bundle, monorepo/polyrepo.
- Elegir la esquina correcta según la restricción real del producto, no según la moda.
- Nombrar conscientemente lo que se renuncia en cada elección.
SSG contra SSR: el eje es la frescura
La primera disyuntiva es cuándo se genera el HTML. En SSG —Static Site Generation— el HTML se produce en el build y se sirve como archivo estático desde un CDN; en SSR —Server Side Rendering— se produce en cada petición, en un servidor o en el edge. El eje que las separa es la frescura del dato frente al coste por petición.
SSGbrilla cuando el contenido cambia poco y es igual para todos: documentación, blogs, marketing. El HTML se genera una vez y se sirve millones de veces a coste casi cero, con la latencia mínima que da un archivo en el edge.SSRbrilla cuando el contenido es personalizado o volátil: un panel con datos del usuario, un precio que cambia por minuto. Paga cómputo en cada petición a cambio de servir siempre el estado actual.
La trampa es tratarlo como binario. Los frameworks modernos —Astro, Next, SvelteKit— permiten mezclar por ruta: estático el blog, servidor el panel, y ISR o revalidación para lo que está en medio. La pregunta madura no es “¿SSG o SSR?”, sino “¿qué frescura necesita cada ruta y cuánto cómputo justifica?”.
flowchart TD
q[Que necesita esta ruta] --> fresh{El dato cambia por peticion}
fresh -->|No, igual para todos| ssg[SSG: genera en build sirve del CDN]
fresh -->|Si, personalizado o volatil| ssr[SSR: genera por peticion en el edge]
fresh -->|Cambia lento| isr[Revalidacion incremental]
style ssg fill:#a6e3a1,color:#11111b
style ssr fill:#f38ba8,color:#11111b
style isr fill:#fab387,color:#11111bBundle contra no-bundle: el eje es la fase
La segunda disyuntiva enfrenta empaquetar el código en pocos archivos contra servir módulos ESM nativos sin empaquetar. Parece una elección, pero Vite ya te enseñó que la respuesta correcta es “las dos, según la fase”. El eje es desarrollo frente a producción.
- En desarrollo, no empaquetar gana. El navegador pide los módulos ESM que necesita bajo demanda; el arranque es instantáneo aunque el proyecto tenga miles de archivos, y el HMR solo recompila el módulo que tocaste. Empaquetar en dev sería pagar un coste que no compra nada.
- En producción, empaquetar gana. Servir miles de módulos sueltos por HTTP castiga con latencia de red y peticiones en cascada. El bundler une el grafo, hace
tree shaking, trocea enchunksy minifica, para que el navegador descargue lo mínimo en el menor número de viajes.
La consecuencia incómoda de usar dos caminos —ESM sin empaquetar en dev, bundle en prod— es que no son idénticos. El orden de ejecución de los módulos, la interoperación entre ESM y CommonJS, el tree shaking que elimina código con efectos secundarios: todo eso puede comportarse distinto entre las dos mitades. Por eso Rolldown como motor único de Vite importa tanto más allá de la velocidad: al recorrer las dos mitades el mismo árbol, la paridad entre dev y build deja de depender de que dos motores distintos coincidan. Hasta que esa unificación es total, la regla de oro sigue vigente: prueba siempre el build de producción antes de desplegar, porque “en dev funcionaba” no es garantía.
Monorepo contra polyrepo: el eje es el acoplamiento
La tercera disyuntiva es cómo repartes el código entre repositorios. El eje es compartir sin fricción frente a aislar con límites duros.
Monorepo cuando...
Varios equipos comparten código que evoluciona junto. Un cambio y su consumidor se ven en el mismo commit, catalogs unifica versiones y el affected construye solo lo tocado. Su precio: una capa de caché obligatoria y disciplina de límites.
Polyrepo cuando...
Los proyectos evolucionan a ritmos y con dueños distintos, o publicas para terceros. Cada repo tiene su ciclo y su despliegue independiente. Su precio: compartir código exige publicar paquetes y las versiones divergen.
La confusión habitual es creer que monorepo significa “un solo artefacto” o que polyrepo significa “sin herramientas compartidas”. Ninguna es cierta: un monorepo despliega muchas apps independientes, y un polyrepo puede compartir configuración por paquetes publicados. Lo que de verdad decides es dónde vive el límite de acoplamiento: dentro del repo, donde un refactor cruza paquetes en un commit, o entre repos, donde ese mismo refactor exige publicar, versionar y actualizar en cadena.
| Disyuntiva | El eje real | Elige A cuando | Elige B cuando |
|---|---|---|---|
| SSG / SSR | frescura vs coste | contenido estable y global | dato personalizado o volatil |
| Bundle / no-bundle | dev vs prod | build de produccion | dev server y HMR |
| Monorepo / polyrepo | compartir vs aislar | codigo acoplado y compartido | ciclos y duenos distintos |
El criterio, no el dogma
Las tres disyuntivas comparten una estructura: hay un eje, hay dos esquinas, y la esquina correcta depende de una variable del producto, no de la moda del año. El error del dogmático es fijar la esquina antes de conocer la variable —“siempre SSR”, “monorepo para todo”— y luego pasar el proyecto compensando una elección que no encajaba. El criterio consiste en el orden inverso: primero nombras la variable, después eliges la esquina, y siempre declaras lo que renuncias.
Hay un momento en la carrera de todo ingeniero en el que deja de preguntar “¿cuál es la mejor herramienta?” y empieza a preguntar “¿mejor para qué restricción?”. Ese giro es la madurez arquitectónica, y es lo que separa a quien repite las opiniones de moda de quien decide con criterio. Ninguna de las grandes disyuntivas de este oficio —SSG contra SSR, empaquetar contra no empaquetar, monorepo contra polyrepo— tiene un ganador absoluto, y creer que lo tiene es la señal más fiable de inmadurez técnica. Cada una es un eje con dos esquinas, y cada esquina es óptima para un valor distinto de una variable concreta: la frescura del dato, la fase del ciclo, el grado de acoplamiento entre equipos. El arquitecto competente no memoriza qué esquina “gana”; identifica qué variable gobierna la disyuntiva, mide su valor en su producto, elige la esquina que encaja y —esto es lo decisivo— nombra en voz alta lo que está renunciando al elegirla. Elegir SSG es renunciar a la personalización por petición; elegir monorepo es aceptar una capa de caché obligatoria; elegir no empaquetar en dev es aceptar que dev y prod difieren. Un compromiso nombrado es una decisión de ingeniería; un compromiso ignorado es una deuda que cobrará intereses en producción. Y hay un corolario que casi nadie enuncia: como la variable cambia con el tiempo —el contenido estático de hoy se vuelve personalizado mañana, el proyecto solitario de hoy se vuelve una plataforma de equipos—, la decisión correcta también caduca, y parte del oficio es reconocer cuándo la restricción cambió tanto que la esquina que elegiste dejó de encajar. Decidir con criterio no es acertar para siempre; es acertar para la restricción de hoy, sabiendo exactamente qué pagaste y bajo qué condiciones tendrás que revisar la decisión. El dogmático defiende su elección; el arquitecto la audita.
- Toma un proyecto real y clasifica cada ruta como
SSG,SSRo revalidación; justifica cada una por la frescura que necesita el dato. - Verifica que tu proyecto no empaqueta en dev y sí en prod, y prueba el build de producción para detectar cualquier divergencia con dev.
- Para tu repositorio, nombra el eje real —compartir o aislar— y argumenta si monorepo o polyrepo encaja con el acoplamiento entre sus equipos.
- Por cada una de las tres decisiones, escribe en una frase qué estás renunciando al elegir tu esquina.
- Identifica una decisión de arquitectura que tomaste hace tiempo y comprueba si la variable que la justificaba sigue teniendo el mismo valor hoy.