La mayoría de los desarrolladores ha oído hablar de la arquitectura de microservicios, pero el término micro front-end es mucho menos conocido. Como el nombre sugiere, el micro front-end es un concepto similar al de los microservicios. Intenta resolver muchos de los mismos problemas que las aplicaciones monolíticas presentan: son demasiado grandes, exigen demasiado esfuerzo y es demasiado complicado realizar cambios en ellas. Además, la incorporación de nuevos empleados para que trabajen con estas aplicaciones puede ser un proceso muy pesado. Por otro lado, si hay varios equipos de personas trabajando en diferentes partes de la aplicación, tendrán que coordinar entre ellos todos los cambios que realicen.
Los microservicios le ayudan a dividir el back-end en varios servicios independientes. El mismo enfoque puede usarse para dividir las aplicaciones de página única (SPA por sus siglas en inglés) en aplicaciones más pequeñas, lo que hace que se necesite un “orquestador” adicional para reunir de nuevo las diferentes partes para que el usuario siga experimentando el comportamiento de una SPA.
¿Cuáles son las alternativas a una arquitectura de Micro Front-end?
Por supuesto, hay otras maneras de hacer frente a algunos de los aspectos no deseados de las aplicaciones muy grandes, como la separación de parte del código en su propio paquete npm. Esto puede resolver parte del problema, como el hecho de que el repositorio sea demasiado grande. Por ejemplo, en Angular, también se puede separar el código en un módulo que puede cargarse en diferido. Gracias a ello, la aplicación se puede dividir verticalmente hasta cierto punto. Pero también tiene sus desventajas, como el hecho de tener que compilar el proyecto de nivel superior cuando una de las dependencias se actualiza. Además, la experiencia del desarrollador no es tan buena. Cuando se usa algún tipo de marco de trabajo, es muy recomendable actualizarlo todo a la misma versión, pero esto supone una tarea inmensa que nadie tiene muchas ganas de hacer. También existe la opción de unir múltiples aplicaciones a través de un iframe. Esto hace que las aplicaciones sean independientes, pero quizá, diría yo, demasiado independientes, ya que la comunicación entre aplicaciones pasa a ser un problema y, con ello, también la compartición de códigos, estilos, etc.
¿Micro Front-ends al rescate?
Los micro front-ends son una combinación de estos dos enfoques. Cada micro front-end es una aplicación separada que se compara con la SPA. No está compilada en un index.html con un script vinculado y archivos de estilo, sino en un módulo JavaScript. En lugar de un iframe en la aplicación “principal”, el código establece que cuando la URL coincida con un determinado patrón, el módulo se cargue en diferido y se coloque en un punto concreto. Gracias a ello, podemos tener varias aplicaciones en la misma página que pueden estar interconectadas entre sí.
De resultas de esto, los micro front-ends no necesitan gestionar el diseño de las aplicaciones y las reglas CSS que solo pueden gestionarse en la aplicación principal. También es igual de beneficioso el hecho de que si tengo múltiples micro front-ends que usan la misma versión de React, puedo hacer que compartan el módulo de React. Es decir, no hay que descargarlo por separado para cada micro front-end. Y tampoco es un problema el hecho de tener diferentes versiones de un módulo JS.
La preocupación principal asociada a los micro front-ends es cómo asegurarse de que sus estilos no se desbordan y llegan a otras partes de la aplicación. Por suerte, los marcos de trabajo de la interfaz de usuario más usados tienen herramientas que permiten abordar esta cuestión fácilmente.
Herramientas para las arquitecturas de Micro Front-end
El hecho de escribir su propio código para cargar las aplicaciones micro front-end le supondría mucho trabajo. Por suerte, existen diversos marcos de trabajo que pueden encargarse de la orquestación y que ofrecen herramientas para convertir las aplicaciones escritas en los marcos de trabajo más populares al formato micro front-end.
En Pure, hemos elegido single-spa. Las principales ventajas que le hemos encontrado es que es fácil de entender, ofrece un amplio soporte para los marcos de trabajo de JS y tiene una documentación muy detallada. Además, single-spa ofrece diversos tipos de micro front-ends, cada uno de ellos adecuado para unos trabajos ligeramente distintos.
Por el momento, solo estamos usando el tipo “Aplicación”, porque es el más fácil de usar para los movimientos desde la SPA hasta los micro front-ends. Los otros tipos también requieren una arquitectura de micro front-end más detallada. Además, el tipo “Aplicación” también es el que recomiendan por defecto los autores de single-spa.
