Venimos del anterior artículo de la serie Microfrontends I: Introducción
Beneficios
Construir en piezas pequeñas trae todas las ventajas de los componentes a nivel de aplicación: reducimos complejidad, funcionalidad y responsabilidad acotadas, tests sencillos, mejor mantenibilidad, menor acoplamiento, bases de código más ligeras, etc.
La funcionalidad se vuelve más escalable, es decir, levantar un nuevo microfrontend es más barato, o al revés, tirar un microfrontend a la basura es menos caro que cuando trabajamos con monolitos acoplados (Figura 2).
Figura 2. Funcionalidad escalable
El punto anterior nos lleva de forma natural al siguiente: ahora las actualizaciones de código pueden ser incrementales, sin impactar al resto de microfrontends existentes. Por tanto reducimos el riesgo de deuda técnica (Figura 3).
Figura 3. Actualizaciones incrementales
Podremos tener repositorios, pipelines, despliegues, entornos y procesos independientes por cada microfrontend. Y ¿por qué no? equipos autónomos (Figura 4).
Figura 4. Equipos y procesos independientes
Retos
Cada microfrontend será una aplicación en si misma, y por tanto un bundle con todas sus dependencias. Es decir, cada microfrontend arrastra sus dependencias, lo cual es ventajoso para poder integrar microfrontends con distintas versiones de una misma tecnología, o incluso tecnologías mixtas. Sin embargo, también puede generar redundancia (Figura 5). El navegador tendrá que descargar más código y se añade más peso a la solución completa. Habrá que contrarrestarlo recurriendo al lazy loading o a técnicas muy recientes y novedosas como la federación de módulos de webpack 5.
Figura 5. Versiones redundantes
Los contratos e interfaces de los microfrontends son críticos (Figura 6). Una aplicación host o anfitriona que consuma varios microfrontends debe saber qué forma tienen, como es su interfaz, como debe llamarlos. Este contrato debería ser compatible entre todos los microfrontends de nuestro proyecto u organización. Y también debería ser sencillo pero fácilmente ampliable. Requiere de un análisis previo importante para evitar cambios de última hora en elementos críticos que penalizan bastante.
Lo ideal es poder dividir la funcionalidad de nuestro proyecto en módulos totalmente estancos. De este modo, cada microfrontend será completamente ‘standalone’ . Pero no siempre es posible, en muchos casos los microfrontends tendrán que ‘hablar’ o compartir un estado global que permita orquestar a nivel de aplicación host. En otros casos querremos poder compartir algún elemento común entre todos los módulos (por ejemplo un theme para estilar). Los elementos comunes son críticos (Figura 6), y la tecnología elegida para ellos también.
Figura 6. Contratos
¿Cuando usar arquitectura de microfrontends?
Por todo lo expuesto anteriormente, diremos que los microfrontends son adecuados para grandes proyectos o aplicaciones en donde la funcionalidad sea fácilmente aislable y modular.
Por el contrario, se desaconseja si:
Se trata de aplicaciones sencillas, desarrollos cortos, etc. ya que sería overkill y es muy probable que acabemos haciendo sobreingeniería.
O bien si la funcionalidad está altamente acoplada, con un estado muy complejo que demande mucha comunicación entre módulos, se nos hará complicado dividir y establecer microfrontends independientes.
Continuará en Microfrontends III: Enfoques y Aproximaciones