Monorepo vs polirepo para microfrontends

Lo central en los microfrontends es el despliegue independiente. Dónde vive el código es una decisión aparte. Un monorepo y un repositorio por equipo pueden funcionar, con costos distintos.

Dos decisiones que se confunden

Es común suponer que los microfrontends exigen un repositorio por equipo. No es así. Un microfrontend se define por compilarse y desplegarse de forma independiente. Eso se puede hacer desde un solo repositorio, siempre que el pipeline compile y publique solo lo que cambió.

La pregunta del repositorio trata de otra cosa: cómo se comparte el código, cómo se actualizan las dependencias y cuánta autonomía tiene cada equipo sobre sus herramientas.

Monorepo

El host, todos los remotos y las librerías compartidas viven en un repositorio. Nx es una opción común para esto en el mundo Angular.

Lo que obtienes

• Una sola versión de cada dependencia. Un único package.json y un lockfile hacen que todos los remotos usen la misma versión de Angular. Los singletons compartidos en ejecución son simples porque no hay nada que alinear.
• Cambios atómicos. Un cambio en una librería compartida y en los remotos que la usan va en un solo pull request.
• Compartir código es fácil. Una librería compartida es una carpeta. Sin publicar paquetes ni subir versiones.
• Límites que se hacen cumplir. Las reglas de lint de Nx pueden prohibir imports entre áreas, así un remoto no puede meterse en el código de otro.
• Builds de lo afectado y caché. Nx calcula qué proyectos toca un cambio y compila y prueba solo esos.

Lo que cuesta

• Las actualizaciones son para todos a la vez. Subir la versión del framework es un cambio grande que todos los equipos absorben juntos. Es eficiente cuando sale bien y bloquea cuando un área es difícil de actualizar.
• El CI depende de las herramientas. Sin comandos de afectados y sin caché, el tiempo del pipeline crece con el repositorio. Alguien tiene que ser dueño de esa configuración.
• Compartir es demasiado fácil. Cuando importar desde otra área no cuesta nada, el acoplamiento crece, salvo que las reglas de límites sean estrictas.
• Las publicaciones independientes exigen disciplina. El pipeline debe desplegar solo los remotos afectados. Si cada merge publica todo, tienes un monolito con pasos extra.

Polirepo

Cada equipo tiene un repositorio para su remoto. El host y las librerías compartidas tienen los suyos.

Lo que obtienes

• Autonomía completa. Cada equipo decide cuándo actualizar y cómo arma su pipeline, dentro de las reglas de la plataforma.
• Propiedad clara. El límite del repositorio es el límite del equipo. Los permisos, las revisiones y el historial son simples.
• Actualizaciones independientes. Un área puede pasar a una versión nueva del framework mientras otra espera, dentro de lo que permiten las reglas de dependencias compartidas.

Lo que cuesta

• El código compartido se vuelve paquetes. El design system, los tipos del contrato y las utilidades deben publicarse y versionarse. Cada cambio es una publicación seguida de actualizaciones en cada consumidor.
• Deriva de versiones. Sin un esfuerzo activo, los remotos terminan en versiones distintas del framework y del design system. En ejecución eso significa código duplicado o errores de carga. Mira dependencias compartidas y versiones.
• Configuración duplicada. La configuración de build, las reglas de lint y los pipelines se copian y después divergen. Las plantillas y los generadores lo reducen.
• Cambios transversales lentos. Un cambio que toca todos los remotos necesita un pull request por repositorio y alguien que los persiga.

Lado a lado

Cómo elegir

• Elige monorepo si los equipos pertenecen a una misma organización, usan el mismo framework y quieres que la alineación de versiones sea automática.
• Elige polirepo si los equipos están lejos entre sí, por ejemplo unidades de negocio o proveedores distintos, o si necesitan reglas de publicación o stacks diferentes. También encaja cuando un área es legacy y va a seguir mucho tiempo en un stack antiguo.
• Un camino intermedio es común: un monorepo por dominio o departamento grande, con el design system y el contrato publicados como paquetes entre ellos.

Elijas lo que elijas, automatiza la actualización de dependencias. Una herramienta como Renovate abre pull requests de actualización en cada repositorio, y es la principal defensa contra la deriva en un polirepo.

Más en esta sección

• De monolito frontend a microfrontends, paso a paso
• Una app AngularJS legacy dentro de un host de microfrontends
• Equipos, límites de propiedad y ley de Conway
• El costo real de los microfrontends