Esta charla la dimos en Talks by Pomelo con Andy Cuello. Contamos cómo el dashboard de Pomelo pasó de un monolito a una arquitectura de microfrontends, y por qué en algún momento eso dejó de ser un lujo y se volvió necesario.
De dónde arrancamos
Arrancamos con un monorepo. Para el MVP fue lo mejor que podíamos hacer: íbamos rápido y reutilizábamos código por todos lados. El problema llegó después, cuando crecimos. Los deploys se empezaron a pisar entre sí y ya nadie tenía del todo claro qué parte era de quién. Todos tocaban todo.
Cómo lo fuimos partiendo
Cuando tuvimos que sumar países y productos, no quedó otra que romper la app en pedazos. Lo probamos de dos maneras.
La primera fue separar en build-time: distintos repos, paquetes de NPM. Ganamos autonomía para escribir código, pero el cuello de botella seguía intacto, porque a la hora de deployar seguíamos atados al mismo flujo.
La segunda, la que nos terminó cerrando, fue integrarlos en runtime. Cada microfrontend se volvió autosuficiente y se arma en el momento con un reverse proxy y Module Federation. Ahí sí pudimos deployar cada parte por su cuenta, sin recompilar toda la aplicación.
Lo difícil no fue lo técnico
Cuando descentralizás, lo primero que corrés riesgo de perder es la consistencia. Que cada equipo termine dibujando su propio botón. Para eso armamos Paradise, nuestra librería de componentes, con un design system atrás que mantiene todo parejo aunque cada uno vaya a su ritmo.
Pero si me tengo que quedar con una sola cosa de todo esto, es que el problema más grande nunca fue técnico. Fue coordinar gente. Podés tener las mejores herramientas, pero si los equipos no se hablan, la autonomía se te convierte en caos. Eso fue lo que más nos costó, y lo que más aprendimos.
Si estás pensando algo parecido o te pica la curiosidad, escribime y lo charlamos.