Arquitectura Microfrontends

Desde un poco antes del 2016 se estaba popularizando un tipo de arquitectura en el frontend, llamada MicroFrontend. Hoy en día, podemos encontrarnos a grandes empresas internacionales utilizándolo en su día a día. Pero ¿en qué consiste? ¿realmente es algo novedoso?

Una realidad de las grandes empresas, es que en muchas ocasiones acaban desarrollando aplicaciones y/o webs de un gran tamaño y complejidad, que les puede llevar años desarrollar y una gran cantidad de personas y equipos de desarrollos, que a menudo, están distribuidos por diferentes países.

Contexto

Anteriormente existían diferentes aproximaciones para poder conseguir finalizar el software, que fuera estable durante un largo periodo de tiempo y que además, fuera mantenible. Para ello algunas de las soluciones era hacer uso de portales estilo Liferay o de Oracle, los queridos y temidos Iframes o simplemente, utilizar las pestañas del navegador o desarrollarlo y luego adaptarse como se pudiese.

Además, con un público objetivo cada vez más global y más numeroso, provocando la evolución de las Arquitecturas backend, orientando su diseño a la escalabilidad, reutilización, flexibilidad y orientación a negocio. Hoy en día, la mayoría de las arquitecturas que nos encontraremos serán con microservicios. Un ejemplo de su evolución sería:

Como podéis ver en los diagramas anteriores, en la última fase indicada, tendríamos un backend separado en piezas más pequeñas. Esto sería, en parte, para buscar su escalabilidad, mantenimiento, orientación a cliente, etc… Pero si observamos el frontend, sigue siendo igual que en el paso anterior, dónde tenemos una gran pieza acoplada.

En años anteriores, un paso anterior a los microfontends, nos podíamos encontrar con las arquitecturas orientadas a componentes. Con la estandarización por parte de los navegadores de los webcomponents, podíamos conseguir una gran reutilización del código utilizado y acelerar el proceso de desarrollo. Dentro de este tipo de solución, una de las más utilizadas era la de Atomic, donde dividíamos los diferentes componentes en átomos, moléculas, organismos, plantillas y páginas, según el tipo de granularidad que tuviesen. Usado en muchos proyectos con Polymer.

Si lo comparamos con los diagramas anteriores, nos quedaría algo parecido a:

Pero como podéis ver, a pesar de ganar con la reutilización, a la hora de integración, seguiríamos hablando de un solo proyecto. Aunque el resto de proyectos, reutilizarían esos mismos componentes.

En este punto, es donde empezamos a hablar de los Microfrontends, que conocemos hoy en día.

Microfrontends

Cuando hablamos de Microfrontends, estamos hablando de un tipo de arquitectura que ya lleva unos cuantos años a la espalda. Aunque a España a tardado unos años en llegar, podríamos definirla como una arquitectura orientada a pequeñas aplicaciones para integrarlas posteriormente en una central.

Esta arquitectura frontend, la podemos integrar con diferentes arquitecturas del Backend, para optimizar aún más sus resultados. Un ejemplo claro que nos podemos encontrar en algunas empresas, es el uso conjunto del patrón de Backend For Frontend con Microservicios y el Microfrontend. Además, en muchos de los casos, nos podemos encontrar que se sigue usando la arquitectura orientada a componentes reutilizables, integrada con el microfrontend, consiguiendo una mayor reutilización del código y de las funcionalidades.

Si tenemos la suerte de asistir a algún evento tecnológico de España y/o internacional, podremos observar cómo algunas empresas y/o técnicos han ido explicando diferentes formas de utilizar este tipo de solución de arquitectura. Algunos ejemplos serían:

Cada una de ellas, utiliza una aproximación diferente para abordar los Microfrontends.

Opciones Generales

Si dadas ciertas necesidades, al final decidimos implantar este tipo de solución, tendremos diferentes alternativas, según las ventajas que deseemos obtener. Si tuviésemos que englobar las diferentes soluciones, las podrías encasillar en:

• Mono repositorio
• Multi repositorio
• Meta repositori

Cuando hablamos de mono repositorio, nos estamos refiriendo a aquellas soluciones, donde al final todos los proyectos estarán dentro del mismo repositorio. Esto nos puede parecer algo contradictorio con la teoría de Microfrontends, donde estábamos buscando generar proyectos independientes para posteriormente integrarlos. Pero en este caso, lo que nos encontraremos será un sistema de dependencias únicas para todos los proyectos, y subcarpetas para cada uno de los proyectos. Un ejemplo de esta solución, sería la que nos da por defecto Angular para generar sub aplicaciones internamente.

Por otro lado, en el multi repositorio tendríamos los proyectos en repositorios diferentes. Esto implicaría unos proyectos más aislados y un sistema de dependencias independiente para cada proyecto.

Por último, tendríamos el meta repositorio, el cual sería una estrategia que intentaría combinar las dos anteriores. Tendríamos múltiples repositorios pero adicionalmente, tendríamos uno donde se integrarían todos.

Cada uno de estos sistemas tiene sus ventajas y desventajas, y cada uno tendría diferentes formas para mitigas sus desventajas. Algunas de estas configuraciones las podremos adaptar mediante una adecuada estrategia de integración continua o mediante funcionalidades específicas de git como los submodules.

Opciones Técnicas

Para abordar cada una de las soluciones anteriores, existen diferentes aproximaciones técnicas. Todas ellas las podríamos clasificar en:

• Build-time Integration: creada en tiempo de construcción de la aplicación
• Server-side Integration: integrada en la página por el servidor mientras el usuario va navegando
• Client-side Integration: las micro aplicaciones son descargadas e integradas mediante el navegador

Componentes Reutilizables

A pesar de que los componentes reutilizables, como bien indica su nombre, sean inicialmente solo para pequeñas opciones, pequeñas funcionalidades, etc… en algunos casos, mediante la misma técnica, podemos diseñar y desarrollar micro aplicaciones reutilizables. Esta solución, lo podemos abordar desde un mismo repositorio, integrándolo dentro de nuestro proyecto, o instalándolo como una dependencia de terceros. Además según el framework y/o librerías de renderizado que usemos (angular, react, vuejs, svelte…), tendremos unas opciones u otras.

Un ejemplo de ello, si englobamos además los webcomponents en este caso, serían:

• Vanilla webcomponent
• Angular library
• Lit-element
• Angular Elements
• Stenciljs
• Componentes de Vuejs
• Componentes de Reacjs
• NX Plugins

Iframes

Esta opción tan conocida, solo sería aplicable a soluciones con multi repositorio. Donde estaríamos indicando en cada tag, la web que desearíamos ver.

Micro Proyectos

Una solución que ofrecen en algunos mono repositorios, es la integración de microproyectos dentro. Algunas tecnologías como Angular, NX, etc. nos facilitan unos comandos y un sistema de routing integrado, que nos facilitaría tanto su creación, como su testing y despliegue.

Server Side Includes

En esta opción, tendríamos las diferentes aplicaciones o solo una, y la integración la realizaríamos desde el servidor. Con lo que para nuestra aplicación frontend tendríamos que desplegar dos partes, una para la visualización y otra para gestionar todas las tareas en el servidor. Según la tecnología que utilicemos, nos facilitaría el trabajo Angular Universal (para angular), Next (para React), Nuxt (para Vuejs) y Sapper (para Svelte).

CDN

Mediante el uso de CDNs, cuando el usuario entra en una sección, se descarga el contenido estático de un bucket de AWS, de Akamai y/o cualquier otro servicio que nos facilite esta funcionalidad.

Server Side Integration

Mediante la configuración de Ngnix, Apache o del servidor que estemos haciendo uso, podemos configurar que cuando entre en cierta dirección se cargue la micro aplicación deseada.

Además de todas las opciones comentadas, existen otras más.

Conclusión

En el caso de que nos quisiésemos aventurar a este tipo de arquitectura para nuestros proyectos y/o empresa, deberemos primero analizar nuestras necesidades, para optar tanto la estrategia adecuada, como por las tecnologías más óptimas. Además de poder utilizar varios de estos sistemas a la vez, para poder abarcar tanto proyectos legacy, como proyectos modernos.

Como dijo Darwin: "Las especies que sobreviven no son las más fuertes ni las más inteligentes, sino aquellas que se adaptan mejor al cambio". Lo mismo lo ocurrirá a nuestras aplicaciones.