La revolución de los Micro-Front-End

Por Camilo Contreras

En un producto antiguo, backend y frontend conviven en una única aplicación, algo que se conoce como arquitectura monolítica.

En la mayoría de los proyectos de mediana escala, se suele utilizar una arquitectura especializada, donde tenemos un equipo de frontend, uno de backend y en algunos casos un equipo de Devops, los que se han convertido en áreas bastante amplias y por lo tanto, necesitan más personas especializadas.

Esto causa que en un proyecto obtengamos algo como las figuras que vemos arriba. Al inicio todos empezamos desarrollando como “Fullstack”, pero luego, vamos logrando arquitecturas más adecuadas como es la de “Microservicios”. En ésta, el backend divide los servicios por responsabilidad, logrando una gran modularidad y haciendo que el avance del desarrollo funcione con tiempos independientes.

Este mismo concepto se ha visto como una gran opción para el frontend, ya que cuando la App crece bastante, los tiempos de desarrollo y despliegues independientes se vuelven difíciles de manejar, lo que causa que el equipo de frontend encuentre varios “Cuellos de botella” en su día a día.

Es por esto que se habla de “Micro frontends”, donde se utiliza el mismo principio de separar el frontend por responsabilidades, tal como los Microservicios, para tener proyectos separados en el frontend.

La idea detrás de Micro frontends es pensar en un sitio web o aplicación web como una composición de características que son propiedad de equipos independientes. Cada equipo tiene un área de negocios o misión distinta en la que se preocupa y se especializa. Un equipo es multifuncional y desarrolla sus funciones de extremo a extremo, desde la base de datos hasta la interfaz de usuario.

Es decir, crear micro frontends que se dediquen a una única funcionalidad, o desarrollos que se puedan aislar unos de otros en el frontend, permite generar versiones, disminuir tiempos de desarrollo y de mantención de productos, testear más rápido y crear nuevos servicios a partir de componentes que ya están creados en lugar de partir de cero. Al mismo tiempo, cuando se detecta un problema, se va a lo puntual en lugar de revisar todo el sitio.

Lo anterior se vería parecido a la siguiente imagen.

¿Quiénes lo usan?

Aunque pensé que esta arquitectura era relativamente nueva, muchas Apps grandes ya la usan hace algunos años, como Spotify, Upwork y Hellofresh.

¿Cómo lo usan?

Incluso, podríamos permitir que cada proyecto manejara su propio Framework, lo que haría que nuestro equipo pueda trabajar con el que le parezca más cómodo para lograr la mejor calidad.

Pensemos ahora en una App grande. Desde Angular normalmente utilizamos un patrón modular, donde cada módulo termina siendo una característica representada en el Router.

MyApp.com/

MyApp.com/settings

MyApp.com/manager

MyApp.com/dashboard

Ahora pensemos qué pasaría si MyApp.com/settings fuera una App en AngularJs, MyApp.com/manager fuera una App en Angular y MyApp.com/dashboard fuera una App trabajada con Vanilla JavaScript. Para el usuario sería transparente sobre las tecnologías que estamos utilizando por debajo y cada persona en el frontend podría tomar una responsabilidad en nuestra App, logrando así unir una arquitectura por responsabilidades desde los Microservicios hacia los Micro frontends.

Estructura que debemos considerar:

· Código compartido. Aunque cada módulo o responsabilidad de nuestra App se maneja independientemente, tenemos cosas compartidas para el correcto funcionamiento, como el Routing global o la autenticación.

· Pequeñas Apps como Módulos. Como dijimos anteriormente, cada uno de los módulos de nuestra App será una App ya sea React, Angular, etc.

· Un sistema de bundling que una todo. Como cada una de las pequeñas Apps tiene su propio mecanismo para trabajar, buscaremos integrar una forma de orquestar el producto final de cada uno de estos frameworks desde su producto final después del build (HTML, Css y JS) y a través de algo como Webpack unirlo y usar características como Lazy Loading.

Técnicas

Aunque existen muchas maneras de integrar esta arquitectura, voy a nombrar las que más me gustan.

· Single-SPA “meta framework”: Esta técnica es una de las más sencillas de utilizar. Básicamente se crea un solo proyecto conteniendo cada pequeña App dentro del mismo repositorio y con el Builder, generamos los Build para producción de cada módulo y los unimos.

· IFrames using libraries and Window.postMessage APIs: Esta técnica es excelente si ya tienes un proyecto iniciado y buscas unir varias pequeñas Apps en unidades independientes. Básicamente la idea es insertar cada pequeña App o módulo en un iframe y comunicar cosas como el Routing o la autenticación a través del API de PostMessages.

· Web Components as the integration layer: Esta técnica me gusta mucho, ya que usa Web Components para modularizar todo, funciona muy parecido a la técnica de iframes, pero en lugar de usar un iframe para independizar la responsabilidad, se utiliza un Web component. Es decir, cada pequeña App deberá ser convertida a un Web Component: <app-settings></app-setting>, <app-dashboard></app-dashboard> y así.

Conclusión

En la mayoría de los proyectos de mediana escala se suele utilizar una arquitectura especializada donde tenemos un equipo de frontend, uno de backend y en algunos casos un equipo de Devops, los que se han convertido en áreas bastante amplias y por lo tanto, necesitan más personas especializadas.

En gran medida no se mira la solución completa como parte de un todo. Si bien ha habido grandes avances en lo que respecta el backend, sigue en auge la tendencia del monolitismo en las aplicaciones web.

Hasta ahora, tener un enfoque monolítico para una aplicación frontend grande se ha vuelto inviable. Debe haber una manera de dividirlo en módulos más pequeños que puedan actuar de forma independiente.

La solución es bastante obvia y abarca los mismos principios que funcionan para los servicios backend durante muchos años: dividir el monolito frontend en pequeños fragmentos de IU. Pero la IU no es muy similar a los servicios, es la interfaz entre el usuario final y el producto, debe ser coherente y sin problemas.

Más aún, en la era de las aplicaciones de página única, toda la aplicación se ejecuta en el navegador en el lado del cliente. Ya no son archivos HTML simples, sino que son piezas sofisticadas de software que alcanzan niveles realmente complejos.

Actualmente, una industria que va a la vanguardia en la implementación de esta arquitectura es la banca, ya que necesitan evolucionar sus productos de la forma más amigable y transparente posible para sus clientes, además de asegurar la continuidad operacional en sus servicios.

Desde la experiencia en distintos proyectos para distintas empresas, es realmente difícil adoptar directamente la arquitectura de micro frontends propuesta anteriormente. Muchos otros proyectos tienen una enorme carga de legado que les está impidiendo migrar a una nueva arquitectura. Por esa razón, es vital una solución de medio camino más suave y flexible para permitir una adopción fácil y una migración segura.