La revolución de los Micro-Front-End

Rompiendo la tendencia monolítica de aplicaciones web

Una página web tiene HTML el cual tiene todo un standard en el mercado. Originalmente el HTML era para darle una estructura a la página web, que también puede incluir estilos (CSS), funciones (JAVASCRIPT).

La revolución de la tecnología comienza con la era Pre-móvil la creación de los iPhone, Tablets, Retina, Surface, etc. Y poco a poco estos dispositivos comienzan a integrar HTML5. También estos dispositivos comienzan a tener un tamaño de pantalla más grande para que el usuario tenga más información a simple vista.

El Responsive Design es un enfoque para que la página web se muestre tanto en desktop, como en un móvil, es decir, para todo dispositivo.

En 1995 existía el HTML 2.0 y que más tarde aparecería CSS en el cual ya en aquel momento teníamos un buen HTML y un poderoso CSS.

En 1997 comenzó a verse navegadores con interacciones con HTML 3.0, CSS y un JavaScript muy básico.

Hasta el 2006 se hacían páginas con Frames, relojes Java, gif, páginas con tabla, páginas con Flash, el cual no duró mucho y pasó al olvido.

En el 2006 llegó JQuery presentado en New York, el cual era un selector muy básico. Aquí empezó la revolución con la llegada de AJAX, se comenzó a incentivar a los desarrolladores la escritura de Plugins, en este momento, ya estaba HTML5, CSS3 y JQuery el cual era todo un boom.

Desde ese entonces, aparecen los patrones modulares, para manejar en manera asíncrona y cargar a demanda JavaScript y Node.js, el cual ofrece npm para manejar los paquetes de dependencias y ordenarlas.

La velocidad de acceso es una de las grandes ventajas, un usuario puede esperar un aproximado en 4 segundos en la carga y renderizado de la página ya que, si pasa más de ello, el usuario tiende a cerrar la página u optar por buscar otra, por ello tenemos un ejemplo; Amazon se preocupa mucho en esto, porque es un punto en contra, ya que la experiencia de usuario no es lo más óptimo. Existe una metodología de trabajo llamada diseño interactivo para hacer prototipos, el cual hace mejorar tu producto y dándole una facilidad de carga.

En la actualidad podemos optar por una aplicación isomórfica, el cual tiene el compromiso de ser ejecutable en todo los navegadores y dispositivos que se puede encontrar.

Render es una librería para renderizado que hace que navegadores muestren todos los elementos de manera más consistente y de acuerdo con las normas modernas. Se dirige precisamente, sólo los estilos que necesitan normalización.

Ya que no está fuera de imaginación (ya lo veíamos venir), HTTP/2 envía archivos pequeños para que la página no sea pesada, cambiará la forma de desarrollar una aplicación web.

Angular y React están en todo su apogeo, son las tecnologías rivales el cual las novedades en el ámbito del desarrollo front end, ambas son herramientas que se usan para crear Single Page Application.

¿Cómo debemos plantear los nuevos retos?

En la mayoría de los casos en 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 cuales se han convertido en áreas bien amplias y por lo tanto, necesitan más personas especializadas.

Esto causa que en un proyecto obtengamos algo así como las figuras que vamos viendo 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, se logra una gran modularidad y hace que el avance del desarrollo funcione con tiempos independientes.

Este mismo concepto se ha visto como una gran opción para el Frontend, donde cuando la App crece bastante tenemos el problema de no poder manejar tiempos de desarrollo y despliegues independientes, lo que ocasiona 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 como los Microservicios y podríamos tener proyectos separados en el Frontend. Siendo algo parecido a la imagen de abajo.

Y aún mejor podríamos permitir que cada proyecto manejara su propio Framework, lo cual haría que nuestro equipo pudiese 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 que 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 seria 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.

Los elementos:

· Código compartido. Aunque cada módulo o responsabilidad de nuestra App se maneja independientemente tenemos cosas compartidas para el correcto funcionamiento como es el tema del 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.

¿Quiénes lo usan?

Aunque pensé que esta arquitectura era relativamente nueva, muchas Apps grandes ya la usan hace un buen tiempo. Entre las empresas que se encuentran están Spotify, Upwork y Hellofresh.

Técnicas.

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

· 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, básicamente 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, es decir podríamos tener <app-settings></app-setting>, <app-dashboard></app-dashboard> y así.

Conclusión

§ ¿Qué? En la mayoría de los casos en 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, todos los cuales se han convertido en áreas bien amplias y por lo tanto necesitan más personas especializadas.

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

§ ¿Quiénes han cambiado? Spotify, Upwork y Hellofresh.

§ ¿Cuándo? Desde hace un par de años a la fecha.

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 pueden actuar de forma independiente.

¿Cuál es la solución?

La solución es bastante obvia, abarca los mismos principios que funcionan para los servicios backend durante muchos años: divida 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. Ahora siento que es necesaria una definición del micro 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.

Desde la experiencia en distintos proyectos, para muchas empresas, es realmente difícil adoptar directamente la arquitectura propuesta anteriormente. Muchos otros 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 que sea más flexible para permitir una fácil adopción y una migración segura.