AUTORES
Martino Zito
Director @Bip xTech
Francesco Cioffi
Senior Solutions
Architect @Bip xTech
El estilo de diseño de arquitectura Micro Frontend hace para el frontend de una aplicación lo que los microservicios hacen para el backend, rompiendo las estructuras monolíticas en componentes más pequeños que luego pueden ser ensamblados en una sola página.
Desde una perspectiva tecnológica, en la que la arquitectura de microservicios (MSA[1]) ha reclamado su espacio al permitir la deconstrucción de los artefactos del backend, muchos se preguntan si es posible adoptar ese enfoque también para diseñar y desarrollar frontends.
En este artículo, comenzando con un poco de historia, nos centraremos en el reto que las arquitecturas de microfondos quieren abordar y superar. Evaluamos el estado del arte e intentamos averiguar las posibles evoluciones en un futuro próximo.
Concluiremos este artículo explicando por qué los micro frontales son una búsqueda que merece la pena, y el enfoque que adoptamos actualmente para apoyar a nuestros clientes que, impulsados por la innovación, ya están adoptando este paradigma.
1 Un poco de historia
Antiguamente, cualquier frontend era un monolito. Todas las funcionalidades, ya sea del lado del servidor o del lado del cliente, se colocaban dentro del mismo artefacto de software. En concreto, las lógicas del backend y del frontend estaban fuertemente acopladas con una representación gráfica de los componentes en el lado del servidor.
El primer paso hacia la filosofía de los micro frontales llegó con el enfoque basado en capas; estas “capas” ayudaron a desvincular los componentes gráficos del lado del servidor. A partir de ese momento, los artefactos de software se dividieron en niveles más granulares y surgió el concepto de Single Page Application (SPA).
El término Micro Frontend apareció por primera vez en la literatura hacia finales de 2016 cambiando tanto el nombre como el objetivo de la arquitectura de microservicios. La idea es encontrar una forma de descomponer (o deconstruir) el frontend en varios componentes (o módulos) funcionales y autoconsistentes definidos como micro, con el objetivo de superar uno de los mayores problemas en el desarrollo y gestión de una única base de código.
En los dos años siguientes se produjo un cambio de paradigma, al surgir un enfoque denominado “Backend for Frontend” (BFF). El backend se desglosa en artefactos (lógicos o materiales); esto proporciona un conjunto completo de funcionalidades requeridas por el cliente. Esto permite que los equipos puedan trabajar en un subconjunto de funcionalidades en paralelo. El mismo enfoque puede aplicarse al cliente monolítico (frontend), ya que es posible dividir el frontend en módulos con un desglose basado en la página y/o la funcionalidad, cada parte es completamente propiedad de un solo equipo.
Para superar los límites del cliente monolítico, aparece el concepto de Web Component. La idea es aprovechar el estándar del W3C llamado Custom Elements que permite adoptar el navegador con elementos DOM escritos en Javascript. La idea es crear elementos no sólo para la representación informativa, sino también para utilizarlos con mayor alcance en el contexto del microfrontend.
Actualmente, se han puesto en marcha varias iniciativas en el uso del microfrontend, concretamente gracias al uso del Web Component. IKEA utiliza micro frontend en su tienda online, en cambio Spotify los utiliza en su aplicación de escritorio. Zalando es el propietario del Proyecto Mosaico, una iniciativa que reúne un conjunto de servicios y bibliotecas útiles para el micro frontend.
2 Debilidades del enfoque tradicional
En el contexto del desarrollo, el mantenimiento o la migración de un software, los retos a los que nos enfrentamos están relacionados con el tiempo de comercialización y la mantenibilidad de los artefactos. Por un lado, para el backend, el problema se mitiga con la introducción del estilo arquitectónico de microservicios. Por otro lado, para el frontend los problemas a tratar son principalmente los siguientes:
- 1. Es posible dividir una aplicación en módulos, pero la base de código sigue siendo la misma, por lo que los equipos que trabajan en los artefactos del frontend, al mismo tiempo, deben dedicar algún tiempo a la coordinación.
2. Los tiempos de compilación aumentan en proporción a las líneas de código. Incluso optimizando, cada cambio o integración requiere una recompilación de todo el artefacto.
3. Cuando se interviene en un módulo para modificar la aplicación, hay que volver a desplegar todo el artefacto. El cambio nunca está realmente aislado del resto de la aplicación con un riesgo relevante de regresiones.
4. El despliegue del frontend, tanto para los cambios en un módulo como para la refactorización de toda la aplicación, requiere la gestión de todo el ciclo de despliegue con la consiguiente alteración de toda la aplicación.
De hecho, hemos anulado parcialmente el efecto positivo introducido por los microservicios, en términos de Time to Delivery (TTD) y Time to Market (TTM) (cuando el frontend sigue siendo un monolito).
3 Retos tecnológicos
Basándonos en lo anterior, es claramente útil separar los artefactos (también en el frontend). Veamos los principales retos a los que hay que enfrentarse en los componentes del frontend.
Una vez identificados los módulos independientes y autónomos y definida la microaplicación, es imprescindible disponer de un contenedor (aplicación shell) capaz de agrupar, establecer comunicación entre y armonizar las distintas microaplicaciones.
Los elementos proporcionados por las microaplicaciones se injertan en la aplicación shell. El shell debe ser capaz de acomodar dinámicamente las micro apps, “componiendo” todo el frontend. Cada microaplicación puede actualizarse independientemente del shell.
El shell debe garantizar la comunicación entre los componentes. Un componente interactúa a través de eventos y propiedades. Por lo tanto, es responsabilidad del shell orquestar los componentes alojados de manera coherente en relación con las interfaces declaradas.
Al final, hay que preocuparse por la apariencia de la aplicación. Cuando el navegador carga un componente, en ausencia de directivas, asigna al componente una apariencia determinada. A la hora de implementar un Web Component, debemos tener en cuenta los siguientes principios:
- • el componente debe tener un comportamiento definido, es decir, en ausencia de directivas debe presentarse con características por defecto
• el componente nunca debe influir en el comportamiento del contenedor
• el componente debe permitir al contenedor personalizar su comportamiento
Las consideraciones anteriores conducen a un mayor compromiso de realización y cuidado en el diseño.
4 Por qué elegir Micro Frontends
A pesar de los retos que acabamos de describir, veamos las ventajas de adoptar este enfoque:
- las microaplicaciones son autónomas, ya que cada una tiene una sola responsabilidad
- las microaplicaciones pueden desarrollarse de forma independiente, aumentando el paralelismo
- los subconjuntos del frontend pueden publicarse de forma independiente sin afectar a otras partes del sistema
- los diferentes Web Components pueden desarrollarse en diferentes tecnologías, lo que fomenta tanto la rotación de equipos como la adopción de marcos más actualizados sin que ello afecte a los componentes existentes
- Los Web Components son reutilizables en cualquier frontend distinto de aquel para el que fueron diseñados
5 Dónde estamos hoy
El panorama actual de las herramientas de soporte es bastante diverso y evoluciona rápidamente.
Hay varios frameworks nacidos con el objetivo de crear Web Components, por ejemplo, el proyecto Polymer que luego se convirtió en el proyecto LitElement. El proyecto OpenWC es otro, con el objetivo de apoyar a la comunidad en la creación y el intercambio de Web Components de código abierto, donde encontramos varias bibliotecas y componentes que abrazan la iniciativa. Desafortunadamente, estamos hablando de proyectos que son bastante divergentes en su implementación.
Recientemente han salido al mercado algunas librerías (single-spa, piral.io, frint.js) con el objetivo de proporcionar herramientas útiles a los desarrolladores, en forma de frameworks de desarrollo, para la implementación de aplicaciones basadas en el concepto de Micro Frontend.
También existen algunos marketplaces que pretenden agrupar los Web Components en un solo lugar y ponerlos a disposición de la comunidad. En algunos casos, el enfoque está fuertemente ligado a un solo producto, véase Vaadin o web-components.org, donde se pueden encontrar muchos elementos diferentes. Al no existir directrices ni estándares, ni siquiera de facto, se hace complejo basar una aplicación en Web Components, bajando la inversión.
6 Una visión de mercado
ThoughtWorks, en 2019, etiqueta el micro frontend con el estado ‘Adoptar’ en el Radar Tecnológico. En mayo de 2020, enumera como uno de los principales beneficios, la capacidad de los equipos para escalar en la prestación de servicios distribuidos y gestionarlos de forma independiente. Citan el artículo[2] (en martinfowler.com) como principal referencia de esta técnica.
Sin embargo, en ThoughtWorks, encontramos por la misma época, octubre de 2020, en estado ‘Hold’, el término micro frontend anarchy. Utilizar esta arquitectura como excusa para mezclar una serie de tecnologías, herramientas o frameworks que compiten entre sí en una misma página, dando lugar a la anarquía del micro frontend es una tendencia ciertamente preocupante. De hecho, a día de hoy, no existe un estándar establecido, ni por parte de la comunidad ni de los actores que puedan imponer un estándar de facto en el mercado. En definitiva, hay mucha confusión: aparecen en el mercado empresas que anuncian el patrón; se lanzan librerías para apoyar a quienes abordan desarrollos siguiendo la metodología; se proponen frameworks para apoyar el desarrollo con las principales tecnologías utilizadas para los componentes de frontend.
Las grandes empresas multinacionales se acercan a este paradigma para sus productos en línea. IKEA prefiere dividir un sistema verticalmente para crear sistemas independientes con backend y frontend construidos por el mismo grupo de desarrolladores. La clave del éxito es mantener equipos pequeños. Jeff Bezos lo llama la “regla de las dos pizzas”: si un equipo es demasiado grande para alimentarse con dos pizzas, el equipo es simplemente demasiado grande. Los microfrentes han permitido a DAZN potenciar equipos más pequeños que pueden trabajar de forma independiente. HelloFresh resolvió los problemas de gestión de su aplicación monolítica dividiéndola, de modo que cada microaplicación tiene su propio servidor y un entorno de desarrollo aislado.
Probablemente, a corto plazo habrá un nuevo marco que aborde la resolución de los problemas típicos que se encuentran con esta opción, o algún actor influyente del mercado abordará el tema de forma estructurada que dará lugar a un estándar.
7 Por qué Bip
En Bip xTech, desde mediados de 2020, estamos adoptando el enfoque micro frontend en el desarrollo de algunas soluciones empresariales.
Comenzamos la adopción de este paradigma tras un intenso análisis del mercado y cuidadosas consideraciones sobre el enfoque adecuado, primero desde un punto de vista abstracto, y luego influenciado por contextos reales de entrega. Siempre estamos atentos a las tendencias del mercado para poder adaptarnos a ellas y beneficiarnos de las técnicas emergentes y las nuevas herramientas.
Desde el lanzamiento en producción de los sistemas que se benefician de esta técnica, podemos decir que los beneficios son significativos. Según nuestras estimaciones internas, podemos decir que hemos reducido los esfuerzos de desarrollo en un 30%, con un ahorro en términos de tiempo y costes. Podemos escalar la entrega con grupos de trabajo porque las funcionalidades están bien delimitadas y el código es autónomo e independiente. Las partes del sistema son suficientemente sencillas y la rapidez de la aproximación a cada uno de los componentes aumenta considerablemente, las regresiones, en cada etapa de lanzamiento, disminuyen fuertemente. El esfuerzo dedicado a las pruebas ha disminuido en un 30% y el tiempo de funcionamiento, tras los informes recibidos en AM (Application Maintenance), se ha reducido prácticamente a la mitad. En definitiva, la adopción de micro front ends nos permite migrar el código heredado de forma incremental, sin necesidad de abordar una reingeniería impactante de un solo golpe.
En conclusión, seguimos atentos a la espera del punto de inflexión, centrándonos en contribuir con nuestra experiencia en el campo.
Si está interesado en obtener más información sobre nuestra oferta o desea mantener una conversación con uno de nuestros expertos, envíe un correo electrónico a [email protected] con el asunto “Micro Frontends” y nos pondremos en contacto con usted lo antes posible.