¿Cómo escalan las empresas sus aplicaciones para que haya muchos equipos trabajando simultáneamente en una gran aplicación web? ¿Cómo podemos reutilizar y aprovechar los desarrollos optimizando el coste para la empresa? Es aquí donde entran en juego los micro frontends. En este artículo hablaremos de ello y veremos pros y contras, además de cubrir algunos ejemplos de implementación.
Desde hace varios años se buscan arquitecturas que rompan las aplicaciones monolíticas para evitar los problemas y limitaciones que éstos nos aportan. En backend, por ejemplo, llevan años adoptando microservicios. Y sobre todo aquellas empresas que tuvieron que crecer muy rápido, se encuentran con el problema de grandes proyectos monolíticos que poco a poco van dividiendo y migrando.
En proyectos y aplicaciones web tenemos el mismo problema. Los proyectos nacen y se desarrollan muy rápido y se convierten en monolitos que con el tiempo se empiezan a volver más pesados de actualizar y desarrollar nuevas features.
Desde hace ya varios años se lleva hablando sobre arquitecturas y estructuras organizativas para desarrollar aplicaciones grandes. Patrones para dividir y descomponer el monolito frontend y desarrollarse en trozos más pequeños y manejables, uniéndose como piezas de un puzzle y creando una producto grande y cohesionado. A esta técnica la llamamos micro frontend.
¿Qué es?
"Un estilo de arquitectura donde las aplicaciones frontend se dividen en trozos, integrándose en un todo mayor."
En la empresa donde trabajo desde hace 5 años, tuvimos y tenemos este problema. Nació como startup y en poco tiempo tuvo que crecer de forma exponencial. Cuando me incorporé, nos encontramos con un proyecto monolítico en java en el que se incluía el frontend. Con el tiempo, desde backend se trocearon bastantes artefactos con microservicios y cada vez que quitabamos un trozo de monolito lo festejábamos como la caída del muro de Berlín.
¿Qué pasó con el frontend?
Cuando comprobamos que sólo el arranque del proyecto nos hacía invertir demasiadas horas, decidimos implementarlo fuera y conectarlo mediante una API. Aquí cometimos el primer fallo. Deshicimos un monolito pero creamos otro. Sí, es más moderno y fácil de mantener pero con el tiempo empezamos a ver como un monstruo volvía a crecer….
Además, la plantilla pasó de estar integrada por unas 25 personas en desarrollo a duplicarse y casi triplicarse, teniendo también presencia en varios países. Nos acercamos al micro frontend, pero teníamos equipos demasiado desestructurados y necesitábamos utilizar una biblioteca de componentes centralizada.
Creamos una horizontal para intentar cohesionar los productos, pero el día a día y el cumplimiento de objetivos de negocio nos hacía avanzar muy despacio. Algunos de mis compañeros y yo, que participamos en proyectos de varias verticales, empezamos a desarrollar funcionalidades muy parecidas a las de otra. Sí que teníamos aplicaciones separadas, pero nos faltaba poder aprovechar el trabajo ya creado de un equipo a otro y viceversa.
Necesitamos micro frontends
En este punto vemos la necesidad de aplicar los micro frontends para optimizar el tiempo de desarrollo y coste para la empresa. Aún estamos en fase de adaptación pero ya hemos avanzado algunos pasos y estos son los benefícios:
- Bases de código más pequeñas y mantenibles: son más fáciles de trabajar por desarrolladores y evitamos el acoplamiento involuntario entre componentes. Al ser independientes lo evitamos y empujamos a que sea un frontend más explícito.
- Mejoras incrementales: de esta manera podemos ir poco a poco desacoplando y estrangulando el monolito. Además de que es asumible por la empresa, ya que no es una mega tarea de reescribir todo el código, nos permite entregar unas features sin el agobio del monolito, y además nos ayuda a experimentar con nuevas soluciones de manera más aislada que antes.
- Mayor independencia y autonomía: al igual que los microservicios, la implementación y despliegue está desacoplada del resto, pudiendo subir a producción. También nos permite acoplar de forma puntual más equipos o ayudas externas al producto.
Solución al rescate: Bit
Actualmente hemos empezado a crear componentes comunes con Bit. Es una herramienta de código abierto para colaborar en componentes aislados en proyectos y repositorios. Nos permite distribuir componentes de una biblioteca de diseño o un proyecto en un paquete reutilizable independiente en todas nuestras aplicaciones. Además es compatible con React que es el la librería de javascript que utilizamos en la empresa.
¿Cómo funciona bit?
Bit facilita el proceso de colaboración en componentes de UI. Los miembros del equipo pueden compartir, mantener y sincronizar componentes aislados de diferentes proyectos.
- Envuelve cada componente en un paquete npm.
- Automatiza el control de versiones de los componentes según los cambios en sus dependencias.
- Compatible con: React, Vue, Angular, Mocha, Jest.
- Funciona junto con Git, NPM y Yarn.
Es muy sencillo de implementar, puedes hacer los tutoriales aquí.
Desventajas
Una vez vistas las ventajas con los micro frontend, tenemos también que analizar los inconvenientes que podemos encontrarnos:
Tamaño de carga del bundle de producción: Los paquetes generados de forma independiente pueden causar duplicidad de dependencias, aumentando el tamaño en bytes que enviaremos a nuestros usuarios. Para solucionarlo podemos crear una biblioteca de dependencias y decidir cuáles serán las genéricas. Esta parte sería la base de dependencias que consumirían nuestros micro frontends y los esfuerzos para actualizarse deberían de ser mucho menos costosos. Tenemos que ser disciplinados para no crear micro frontends con dependencias innecesarias. Estos impactos de rendimiento hay que tenerlos en cuenta en cada decisión que tomemos en la arquitectura de nuestro producto.
Diferencias entre entornos: Los micro frontend tienen la capacidad de poder desplegarse en entornos propios para el desarrollo y probarse de forma independiente. Sin embargo es posible que el desarrollo no se comporte igual por separado, que integrado en conjunto y desplegado en un entorno de producción. Para ello debemos probar en entornos que sean lo más parecidos a producción y hacer pruebas manuales y automatizadas para detectar problemas.
Complejidad operacional: Tener más bases de código conlleva más trabajo para administrar. Más repositorios, servidores, entornos de desarrollo, dominios...etc.
Deberíamos de tener en cuenta:
- Las repositorios tienen la suficiente automatización para aprovisionar y administrar la infraestructura requerida. Es posible que tenga que tener un equipo de devOps detrás de estos proyectos.
- Los procesos de despliegues, pruebas y lanzamiento se adaptan a muchas aplicaciones.
- Cómo garantizamos un mínimo de calidad y coherencia entre todas las bases de código.
Conclusión
La tendencia en frontend es crear aplicaciones cada vez más complejas y con muchas funcionalidades. Es necesario crear arquitecturas más escalables. Debemos poder estructurar y cohesionar piezas que sean como un puzzle; fáciles de montar y desmontar y sobre todo de testear, así como de integrar software de calidad entre equipos autónomos con una visión común. Todavía nos queda mucho camino que recorrer. Pero es obvio que avanzamos a pasos agigantados en metodologías y patrones arquitectónicos, para construir grandes aplicaciones y productos de forma ágil y con la calidad que se merecen.
¡Gracias por leer mi artículo!