Probablemente hayas escuchado el término microfrontend, pero te suena a hype pasado de moda; sin embargo, microfrontend es una práctica vigente y, al igual que los microservicios, se ha convertido en un estilo de arquitectura para organizar y escalar el desarrollo de aplicaciones y sistemas.

Microfrontend toma los conceptos que conocemos de microservicios y los aplica a la capa de presentación con el objetivo de tener unidades o bloques de desarrollo que se puedan implementar y desplegar de forma independiente, pero para los proyectos de frontend. Igualmente que los microservicios, microfrontend necesita de gobernanza para no generar desorden y caos; es decir, microfrontend tiene mucho sentido cuando tu solución va creciendo en complejidad, ya sea que esta complejidad se vea reflejada en funcionalidades o en dominios de negocio y, por ende, necesites poder escalar, ya que es casi seguro que necesitarás múltiples equipos para poder gestionar toda esa complejidad.

Veamos ahora los principios técnicos y organizativos que rigen la arquitectura de microfrontends según la teoría.

Principios técnicos

• Autonomía funcional, no por tecnología. Es decir, crear un nuevo microfront debe responder a capacidades de negocio y no técnicas,
• para evitar tener componentes que no tienen sentido funcional.
• Despliegue independiente. Se sobreentiende que el ciclo CI/CD, así como la infraestructura, son independientes.
• Contratos de comunicación claros. Cómo será la interacción entre MFEs: por ejemplo, eventos, contratos de API o servicios compartidos.
• Performance. Se puede aplicar carga diferida y controlar el uso de librerías, así como controlar la duplicidad de estilos.
• Aislamiento tecnológico. En teoría, cada MFE puede usar sus propias librerías y frameworks, así como aislar CSS y estado.

Principios organizativos

• Propiedad end to end. Cada equipo es responsable de su microfrontend, desde el desarrollo hasta llegar a producción.
• Estrategia de orquestación. ¿Cómo se integran los microfronts? ¿En compilación o en ejecución? De esto dependerán el versionado y el despliegue.
• Estandarización. Políticas de seguridad, frameworks permitidos y políticas de performance.
• Observabilidad. Los microfrontends deben poder monitorearse e identificarse en su traza y logs.
• Sistema de diseño y usabilidad. Aunque sean equipos distintos, como se tiene el contexto de un contenedor, los microfronts deben estandarizar su sistema de diseño y navegación.

Recomendaciones basadas en mi experiencia

En base a mi experiencia retaré estos principios teóricos para llevarlos a un escenario de implementación real. Para ello, doy las siguientes recomendaciones:

Cuándo calzan bien

Los microfronts encajan bien con una figura modular dentro de un sistema mucho más grande. Por ejemplo, un sistema core a medida: un módulo de RRHH o contabilidad serían microfronts separados dentro de un sistema administrativo. En mi experiencia, este tipo es el mejor caso de uso, ya que tienen un alcance funcional claro y los pueden ver equipos y células con real independencia.

Cuándo no calzan bien

No encajan bien para construir widgets o componentes reutilizables. Se puede lograr, pero generan mucha complejidad frente a opciones más simples como una arquitectura de plugins o componentes. Por ejemplo, es mucho más simple reutilizar widgets tipo agendamiento y chatbots mediante scripts clásicos, y para componentes meramente visuales es mucho mejor implementar Web Components.

Estrategia de repositorios

Utilizar multirepo desde el inicio me parece la mejor estrategia de gestión de fuentes, ya que logras real independencia y fortaleces la seguridad cuando tengas que otorgar accesos a los equipos. Es cierto que genera complejidad para gestionar pipelines y CI/CD, pero el punto de seguridad y no descargar un repositorio muy grande lo compensan.

Comunicación backend

Cada MFE debe tener su propia capa de API Backend for Frontend (BFF). Con esto se logra real independencia; es decir, si un microfront se cae, no afectaría al resto.

Comunicación entre microfrontends

Para la comunicación entre microfrontends a nivel local, es ideal definir un estado global para todos los microfronts con un alcance claro (ejemplo: el contexto de sesión de usuario) y luego que cada microfront tenga su propio estado de acuerdo a su lógica de negocio. Para la comunicación entre el contenedor y los microfronts se pueden usar eventos de JavaScript.

Librerías y frameworks

Utilizar diferentes librerías y frameworks entre microfronts es contraproducente. Al inicio del hype de microfrontend este fue el principal gancho, ya que era el sueño de los frontenders, pero en la realidad esto genera una complejidad y retos técnicos enormes que no se compensan en escenarios corporativos ni para equipos pequeños. Por ejemplo, está el reto de compartir estado entre diferentes frameworks que lo gestionan de forma muy distinta, y ni hablar de la dificultad para conseguir perfiles que puedan mantener toda esa variedad.

En móviles

He visto intentos de llevar el concepto de microfrontend a las aplicaciones móviles, pero esto no me hace mucho sentido, ya que una app bien definida tiene un alcance funcional pequeño. Dividir en microfrontends sería extremo y redundante. Las implementaciones reales que he visto de esto lo que realmente hacen es implementar módulos de Android, por ejemplo.

Ejemplo práctico con Nx y Azure Static Web Apps

Cerrado el preámbulo de microfrontends, ahora voy a lo bueno: un ejemplo de implementación con Nx Module Federation, React.js y Azure Static Web Apps. El ejemplo consiste en implementar microfrontends y no ahonda en aplicaciones funcionales reales. Se tiene un contenedor y un microfrontend, cada uno en su repositorio usando la estructura de Nx, pero con Nx se puede manejar con ambos escenarios tanto monorepo y multirepo.

Elegí Azure Static Web Apps para el deploy ya que me permite hacerlo de forma muy simple y ágil. Otra opción de implementación sería desplegar en Account Storage con Blob Storage habilitado para sitios estáticos y luego poner delante de este storage un Azure CDN Front Door o un clásico Microsoft CDN. Por otro lado elegí Nx Module Federation por la facilidad para implementar microfrontend.

Dejo el enlace a los repositorios de código fuente, host y microfrontend remoto respectivamente:

Host de microfrontend con Azure Static Web Apps

Microfrontend remoto “Remote 1” en Azure Static Web Apps

Para resumir este ejemplo de implementación, dejo un diagrama de arquitectura referencial a donde apuntar para un escenario real:

Conclusiones

1. El principal objetivo de microfrontend es la independencia, no la reutilización. Como ya comenté, existen opciones mucho más simples como widgets vía script y Web Components para lograr reutilización.
2. Microfrontend tiene mucho sentido para soluciones y equipos grandes, donde se necesita modularizar y que los equipos no se pisen los pies al momento de desarrollar.
3. Mantenerse simple es vital: introducir complejidad innecesaria como múltiples librerías y frameworks solo genera dificultades que no aportan al negocio y hacen perder de vista los objetivos más importantes, como la independencia.

---

Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades

Referencias

• Configure front-end frameworks and libraries with Azure Static Web Apps