Cómo funcionan los microfrontends: arquitectura, patrones y ejemplos

Inicio » Python » Cómo funcionan los microfrontends: arquitectura, patrones y ejemplos

Los microfrontends se han convertido en uno de los patrones de arquitectura frontend de los que más se habla. Para equipos que superaron el monolito clásico de una sola página. Cuando hay docenas de desarrolladores trabajando con el mismo código base, los ciclos de lanzamiento se ralentizan, las regresiones se infiltran por todas partes y los pequeños cambios en la interfaz de usuario requieren una coordinación masiva. Los microfrontends abordan precisamente ese problema al dividir la interfaz de usuario en partes construidas e implementadas de forma independiente.

En esta guía repasaremos qué son los microfrontends, por qué aparecieron y cómo se relacionan con los microservicios.Qué ideas fundamentales debes respetar al diseñarlas y cómo funcionan en la práctica con tecnologías como React, Angular, Next.js, componentes web, federación de módulos de Webpack y Single-SPA. También analizaremos en profundidad patrones arquitectónicos reales, buenas prácticas, errores comunes y ejemplos concretos, como un catálogo de productos y un carrito de compras implementados como microfrontends independientes.

¿Qué son los microfrontends y por qué aparecieron?

El término “micro frontends” se popularizó alrededor de 2016 en el ThoughtWorks Technology Radar Como respuesta a una tendencia muy concreta: las arquitecturas de backend se movían hacia los microservicios, pero el lado del navegador seguía siendo un monolito grande y frágil, propiedad de un solo equipo. Con el tiempo, esa SPA de "cliente pesado" se vuelve difícil de evolucionar, a pesar de que el backend está bien dividido en pequeños servicios.

Un microfrontend es esencialmente la idea de microservicio aplicada a la interfaz de usuario del navegador.En lugar de un gran repositorio frontend, la interfaz de usuario se compone a partir de múltiples aplicaciones más pequeñas e independientes. Cada una posee un dominio empresarial claro (por ejemplo, "pago", "búsqueda de productos", "perfiles de estudiantes") y puede construirse, probarse e implementarse a su propio ritmo.

Al igual que los microservicios dividen la lógica del backend en unidades implementables separadas, los microfrontends dividen el frontend en porciones verticales. Que abarcan desde la base de datos o las API, pasando por el backend, hasta la interfaz de usuario. Un equipo multidisciplinario gestiona esa parte vertical de principio a fin, desde el esquema de datos hasta los componentes de la interfaz de usuario.

Esta “organización vertical” contrasta con una división horizontal por capas. (Un equipo para la interfaz de usuario, otro para las API y otro para la base de datos). Los equipos verticales suelen entregar más rápido porque no necesitan coordinar cada pequeño cambio en la mitad de la empresa.

Desde el punto de vista de la aplicación, un microfrontend es una aplicación web autónoma. que puede componerse en una experiencia más amplia: puede tener su propio enrutamiento, gestión de estados, sistema de diseño y pipeline de despliegue, siempre que respete un conjunto de contratos con el resto del sistema (URLs, eventos, APIs, librerías compartidas, etc.).

Ideas y principios fundamentales detrás de los microfrontends

Varios principios recurrentes aparecen en arquitecturas de microfrontend exitosas;No son reglas estrictas pero te ahorrarán mucho dolor si las usas como barandillas.

Agnosticismo tecnológico Es uno de los principios más conocidos: cada equipo debería poder elegir y actualizar su pila tecnológica sin sincronizarse con los demás. Quizás un microfrontend esté en React, otro en Angular y uno heredado en Vue. Las abstracciones nativas del navegador, como los Elementos Personalizados (Componentes Web), ayudan a ocultar esas diferencias tras una API DOM estándar.

Otro objetivo clave es un fuerte aislamiento entre las bases de código de los equipos.Idealmente, los microfrontends no comparten un entorno de ejecución de JavaScript ni variables globales. Cada paquete es autónomo, carga sus propias dependencias y no depende del estado oculto de otros. Esto reduce el acoplamiento accidental y hace que las implementaciones independientes sean mucho más realistas.

Para evitar conflictos de nombres, los equipos a menudo acuerdan espacios de nombres explícitos. Para clases CSS, eventos DOM, claves de almacenamiento local, cookies o incluso nombres de etiquetas de elementos personalizados. Por ejemplo, un equipo de pago podría prefijar elementos con chk- o usa una etiqueta como <blue-buy>, mientras que un equipo de recomendaciones utiliza rec- or <green-recos>De un vistazo, el DOM te dice quién es el propietario de cada pieza.

Otro principio es preferir las capacidades nativas del navegador a las API globales personalizadas.En lugar de inventar un sistema PubSub multipropósito, puede confiar en eventos DOM estándar, CustomEventAPI de historial para enrutamiento o el propio DOM como capa de integración. Siempre que necesite una API compartida, manténgala lo más pequeña y estable posible.

Por último, la resiliencia debe ser parte del diseño desde el primer día.Cada microfrontend debería seguir ofreciendo valor cuando JavaScript es lento, falla o se bloquea. Técnicas como el renderizado del lado del servidor, la mejora progresiva y las pantallas de esqueleto ayudan a mantener un alto rendimiento percibido incluso en condiciones de red deficientes.

¿Qué es una “aplicación web moderna” en este contexto?

No todos los sitios web necesitan microfrontends o una estrategia compleja de integración de navegadores.Un buen modelo mental surge del "continuo documentos-aplicaciones": a la izquierda, se encuentran principalmente documentos estáticos vinculados entre sí; a la derecha, aplicaciones totalmente interactivas, como un editor de fotos en línea.

Si su proyecto se acerca más a los documentos estáticos, una simple composición renderizada por el servidor suele ser suficiente.El servidor recopila fragmentos HTML de diferentes fuentes, los une y los envía al navegador. Las actualizaciones se realizan mediante cargas de página completas o pequeñas inyecciones de Ajax, lo cual es perfectamente normal.

Cuando avanza hacia experiencias más dinámicas, similares a las de una aplicación—Retroalimentación instantánea, trabajo sin conexión, actualizaciones optimizadas de la interfaz de usuario— la integración pura del lado del servidor deja de ser suficiente. Se necesita composición, gestión de estados y enrutamiento del lado del cliente. Ahí es donde los microfrontends cobran interés: ofrecen una forma de escalar esa complejidad entre varios equipos.

Organización vertical y porciones impulsadas por dominios

Una recomendación común es alinear los microfrontends con los dominios comerciales en lugar de las capas técnicas.Piense en términos de recorridos de usuario: «carrito», «detalles del producto», «usuarios administradores», «horarios de cursos», «registros de estudiantes», «facturas», etc.

Cada uno de estos dominios puede convertirse en su propio microfrontend con una responsabilidad bien definida.En un sistema universitario, una aplicación podría gestionar los perfiles de los estudiantes, otra los del personal, una tercera los horarios de los cursos y otra la interfaz de resultados de los exámenes. Comparten una interfaz y quizás algo de estilo, pero cada una es una aplicación independiente desde el punto de vista de la implementación.

Una buena segmentación también considera los contextos delimitados de sus microservicios de backendIdealmente, el microfrontend de "facturación" se comunica principalmente con los microservicios de facturación, el frontend de "catálogo" con los servicios de catálogo, y así sucesivamente. Esto mantiene la cohesión de cada segmento vertical y reduce las dependencias entre equipos.

Integración técnica: DOM como API y componentes web

En las arquitecturas de microfrontend del lado del navegador, el propio DOM a menudo actúa como la API de integración principal.En lugar de llamar directamente al JavaScript de cada uno, los equipos exponen la funcionalidad a través de elementos HTML, atributos y eventos.

Los elementos personalizados (parte de los componentes web) son un primitivo poderoso para esto.Un equipo puede crear una función usando el marco que desee y luego encapsularla como una etiqueta personalizada, por ejemplo <order-minicart></order-minicart>El contrato público de ese componente se define por su nombre de etiqueta, atributos y eventos emitidos, no por su implementación interna.

La compatibilidad del navegador con Custom Elements v1 ahora es sólida en todos los navegadores principales., lo que significa que rara vez necesitas polyfills. La mayoría de los frameworks más populares (React, Vue, Angular, Svelte, Preact) pueden renderizar o incrustar elementos personalizados como si fueran etiquetas HTML normales, y muchos de ellos también pueden compilarse en un elemento personalizado.

El patrón de integración se parece a estoUn microfrontend de "página de producto" decide qué funciones aparecen en la página (selectores, botones de compra, minicarrito, recomendaciones). Inyecta elementos personalizados como <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>Los equipos que poseen esas características registran sus elementos con customElements.define e implementar devoluciones de llamadas del ciclo de vida como connectedCallback or attributeChangedCallback.

Cuando cambia una variante de producto, la página puede recrear el elemento o simplemente actualizar sus atributos.Si el componente observa atributos relevantes, puede volver a renderizarse. Internamente, el componente puede usar cadenas de plantilla, React, Vue o cualquier motor de renderizado; el integrador no tiene que preocuparse.

Comunicación del lado del cliente: eventos y relaciones DOM

El paso de atributos funciona bien en escenarios de “entrada de datos” unidireccionalesPero muchas interacciones reales requieren que los componentes se comuniquen con su entorno o con sus hermanos. Un ejemplo típico es un botón de "comprar", que debe notificar al minicarrito cuando se añade un artículo.

En lugar de crear un bus de eventos global personalizado, puede apoyarse en los eventos del navegador. Envío de componentes CustomEvent instancias que surgen a través del árbol DOM. Un elemento padre o incluso window Puede escuchar esos eventos y orquestar respuestas.

Por ejemplo, el botón de compra podría emitir un evento como blue:basket:changed con la carga útil actual del carritoEl minicarrito se suscribe a ese evento en window o en un elemento contenedor compartido y actualiza su estado interno cada vez que se activa.

Este enfoque mantiene los componentes independientesEl botón de compra desconoce quién, si es que alguien, escucha sus eventos. Simplemente cumple su contrato. Y el minicarrito solo depende de la semántica de los eventos, no de los detalles de implementación de otros fragmentos.

Representación del lado del servidor y componentes universales

Si le importa el rendimiento de la primera pintura, el SEO o la resiliencia cuando falla JavaScript, la representación del lado del servidor (SSR) es esencial.Los componentes web puros del lado del cliente solo aparecen después de que se descarga y se ejecuta el paquete JS, lo que puede significar una pantalla blanca en redes lentas.

Una solución pragmática es combinar elementos personalizados con inclusiones del lado del servidor (SSI/ESI)Cada microfrontend expone un punto final HTTP que devuelve el HTML de su fragmento, por ejemplo /blue-buy?sku=t_porscheLa página principal, renderizada por una shell o aplicación host, incluye marcadores de posición como <!--#include virtual="/blue-buy?sku=t_porsche" --> que el servidor web (a menudo nginx) expande antes de enviar la respuesta al navegador.

En tiempo de ejecución en el navegador, el mismo elemento personalizado se hidrata o se reinicializa. Una vez cargado el paquete JS, se obtiene un componente "universal": se renderiza en el servidor para mayor velocidad y optimización para motores de búsqueda (SEO), y luego se comporta como un elemento personalizado totalmente interactivo en el cliente.

Una desventaja de SSR con inclusiones es que el fragmento más lento determina el tiempo total de respuesta.El almacenamiento en caché a nivel de fragmento es casi obligatorio. Para piezas costosas y altamente personalizadas (como recomendaciones), puede omitir la renderización del lado del servidor y cargarlas asincrónicamente en el cliente.

Las pantallas de esqueleto son un buen compromiso para evitar cambios bruscos de diseño.Un fragmento puede renderizar en el servidor un marcador de posición atenuado con un tamaño aproximado al del contenido final. Cuando los datos reales llegan al cliente, el esqueleto se intercambia sin grandes reflujos.

Carga de datos y rendimiento percibido

En un mundo de microfrontend, hay que pensar detenidamente dónde y cuándo se obtienen los datos.Puedes obtener todo del lado del servidor, del lado del cliente o usar una solución híbrida. Cada opción afecta las estrategias de almacenamiento en caché, el tiempo de interacción y la velocidad percibida.

Las inclusiones del lado del servidor fomentan naturalmente las recuperaciones del lado del servidor por fragmentoCada microfrontend se comunica con sus servicios backend, renderiza HTML y lo devuelve al shell. Este HTML se puede almacenar en caché independientemente de otros fragmentos, lo que facilita la escalabilidad de partes con alto tráfico, como el inicio de sesión o las listas de productos.

Al cargar datos en el cliente, debe presupuestar los estados progresivos: esqueleto inicial, actualizaciones rápidas al cambiar los atributos y comportamiento de respaldo cuando las API son lentas. A veces, mantener los datos antiguos hasta que lleguen los nuevos resulta menos impactante visualmente que actualizar un esqueleto cada vez que se produce un cambio menor.

Microfrontends con React

React es una opción muy popular para implementar microfrontends debido a su ecosistema y optimizaciones de renderizado.El DOM virtual y la comparación facilitan la actualización de pequeñas partes de la interfaz de usuario en función de los cambios de propiedades o del estado global, y puedes agrupar aplicaciones React como SPA independientes o como elementos personalizados.

La migración entre versiones de React tiende a ser incremental y relativamente sencilla. En comparación con otros frameworks, esto resulta útil cuando muchos equipos independientes mantienen microfrontends separados. No es necesario que todos los fragmentos salten de una versión principal a otra al mismo tiempo.

La otra cara de la moneda es que los microfrontends de React descentralizados pueden crear una proliferación de recursos.Múltiples equipos, múltiples pipelines de CI/CD, muchos paquetes, muchos repositorios pequeños. Sin suficiente automatización para la compilación, el aprovisionamiento y la observabilidad, esa sobrecarga se vuelve difícil de gestionar.

Otra cuestión práctica es el tamaño del paquete.Si cada microfrontend incluye su propia copia de React y bibliotecas compartidas, el tamaño total de la descarga puede dispararse, especialmente cuando se necesitan varios fragmentos para renderizar una página. Soluciones como la Federación de Módulos (para compartir dependencias en tiempo de ejecución) o una pila de desarrollo bien alineada entre equipos pueden mitigar este problema.

Microfrontends con Angular

Angular se presta muy bien a configuraciones de microfrontend más dogmáticas., especialmente al usar monorepositorios y sus herramientas (como Nx). Los espacios de trabajo de Angular se organizan en proyectos y bibliotecas, lo que facilita la división de una solución grande en varias aplicaciones y bibliotecas compartidas.

Desde Angular 12 y Webpack 5, Module Federation se ha convertido en un ciudadano de primera claseUn proyecto Angular se puede configurar como host o remoto usando comandos esquemáticos, conectando lo necesario webpack.config.js y lógica bootstrap para ti.

En este modelo, la aplicación Angular “host” actúa como shell Que orquesta la navegación, el estado compartido y la compartición de dependencias. Los microfrontends individuales de Angular (remotos) exponen módulos de Angular que el host puede cargar dinámicamente mediante la carga diferida mediante la federación de módulos.

Todavía se aplican los primitivos de enrutamiento angular habitualesDentro de un microfrontend, se utiliza RouterModule.forChild para las definiciones de rutas secundarias de modo que el host sea el único que las utilice forRootDe esa manera, varias aplicaciones Angular pueden coexistir bajo un espacio de URL unificado sin conflictos de enrutadores.

Federación de módulos en la práctica (ejemplo Angular)

Webpack Module Federation es una característica de Webpack 5 que permite que múltiples compilaciones compartan código en tiempo de ejecuciónUna compilación (el host) carga dinámicamente los módulos expuestos por otras compilaciones (remotas) a través de un pequeño archivo de manifiesto, normalmente llamado remoteEntry.js.

En Angular puedes crear este andamiaje con bastante rapidez.Por ejemplo, podría crear una aplicación host (host-app) y luego ejecutar un esquema como ng add @angular-architects/module-federation --project host-app --port 4200Esto configura una configuración de ModuleFederationPlugin, archivos de arranque y lógica de tiempo de ejecución.

Luego crea dos aplicaciones Angular remotas: una para un catálogo de productos y otra para un carrito de compras.Cada aplicación tiene su propio puerto (por ejemplo, 4201 para products-app, 4202 para cart-app) y su propia configuración de Federación de Módulos. En webpack.config.js de cada control remoto que uses exposes para publicar un módulo (normalmente el módulo principal de la aplicación) bajo una clave como ./ProductsModule or ./CartModule.

Luego, el shell del host define rutas que cargan de forma diferida esos módulos remotos. vía loadRemoteModule de @angular-architects/module-federation. Por ejemplo, navegar a /products desencadena una importación dinámica desde http://localhost:4201/remoteEntry.js y cargas ProductsModule; /cart hace lo mismo con el control remoto del carrito.

Dentro del microfrontend del catálogo es posible que tengas un ProductsComponent que representa una tabla de elementos, leyendo datos de un PRODUCTS_CATALOG Constante y ofrece un botón "Añadir al carrito". Al hacer clic, el artículo persiste en... localStorage bajo una tecla “carrito”, incrementando cantidades cuando el producto ya existe.

Luego, el microfrontend del carrito lee desde el mismo localStorage claveMuestra una tabla con el nombre del producto, el precio, la cantidad y el total, y ofrece un botón "Vaciar carrito" que borra el almacenamiento y restablece su estado interno. Esta es una forma sencilla pero ilustrativa de compartir el estado entre dos aplicaciones independientes sin una conexión estrecha.

Construyendo el shell del host: diseño, inicio y navegación

Un shell de host sólido es fundamental para una buena experiencia de usuario en todos los microfrontends.Generalmente posee el diseño global (encabezado, pie de página, barras laterales), el enrutamiento de nivel superior y, a veces, el estado global como la autenticación o las marcas de características.

En el ejemplo de Angular, el host define un LayoutComponent que representa un encabezado y un anidado router-outletEl encabezado vive en su propio HeaderModule y expone enlaces de navegación a la página de inicio, lista de productos y carrito a través de Angular. routerLinkLas rutas se pueden centralizar en una enumeración como RoutesPath para evitar cuerdas mágicas.

El módulo de enrutamiento de diseño configura una ruta principal con LayoutComponent como su componente y define rutas secundarias para /home, /products y /cart. El /home La ruta carga un local HomeModule; los demás usan loadRemoteModule para incorporar los microfrontends angulares en tiempo de ejecución.

Dentro del host, un SharedModule Puede recolectar bloques de construcción reutilizables. Como encabezado, diseño, directivas comunes y constantes. Este módulo se puede importar al directorio raíz. AppModule para cada año fiscal junto con la AppRoutingModule, que apunta la ruta vacía a la configuración de enrutamiento de diseño.

Next.js y microfrontends

Next.js, como marco de React de nivel de producción, también funciona bien con un enfoque de microfrontend., especialmente desde que adoptó Webpack 5 y, por lo tanto, la compatibilidad con la Federación de Módulos. Su enfoque en SSR, regeneración estática incremental y enrutamiento lo convierte en un buen candidato para el shell, microfrontends individuales o ambos.

Para implementar microfrontends en Next.js, normalmente se configura la federación de módulos en el nivel de WebpackExponer ciertas páginas o componentes como remotos y consumirlos desde un host. Aunque la Federación de Módulos es simplemente una función de empaquetamiento de JavaScript, se puede considerar un patrón arquitectónico: permite cargar dinámicamente código propiedad de diferentes equipos sin empaquetar todo previamente.

Para versiones heredadas de Next.js sin Webpack 5, necesitará adaptadores externos Para habilitar la compatibilidad con federaciones. A partir de Next 10.2, la compatibilidad con Webpack 5 está integrada, lo que simplifica enormemente la configuración.

Single-SPA y otros marcos de microfrontend

Single-SPA es otra solución conocida para microfrontends, particularmente en ecosistemas React.Se centra en orquestar múltiples aplicaciones independientes en la misma página, cada una montada en su propio nodo DOM según la ruta actual.

Con Single-SPA puedes tener varias aplicaciones React (o incluso mezclar React, Vue, Angular) coexistiendoEl marco controla cuándo arrancar, montar o desmontar cada microfrontend a medida que el usuario navega, y lo integra a su estrategia de enrutamiento (por ejemplo, con React Router en cada fragmento).

Al elegir entre Single-SPA y Federación de módulosLos equipos suelen considerar sus preferencias de empaquetador/herramientas. La Federación de Módulos se integra a fondo con Webpack (y, cada vez más, con alternativas como Rspack o Rollup a medida que añaden compatibilidad). Por otro lado, Single-SPA se centra más en la orquestación en tiempo de ejecución que en compartir paquetes, por lo que se puede usar con diferentes herramientas de compilación y, al mismo tiempo, gestionar el uso compartido de código de otras maneras.

Objetivos, características y beneficios de los microfrontends

El objetivo principal de los microfrontends es escalar el desarrollo frontend en muchos equipos sin colapsar por la sobrecarga de coordinación.En lugar de una base de código gigante con lanzamientos sincronizados, obtienes unidades más pequeñas que se pueden implementar de forma independiente.

Los objetivos clave suelen incluir: permitiendo que varios equipos trabajen en paralelo, apoyando la implementación independiente para diferentes partes de la interfaz de usuario, manteniendo la flexibilidad para usar diferentes tecnologías donde tenga sentido y mejorando la capacidad de mantenimiento al reducir el tamaño y la complejidad de cada base de código.

Las características típicas de dicha arquitectura son la reutilización de componentes a través de bibliotecas compartidas., integración modular a través de un shell de aplicación, pipelines independientes por microfrontend, optimización del rendimiento a través de CDN y almacenamiento en caché, manejo de seguridad centralizado y fuerte capacidad de observación.

Desde una perspectiva empresarial, los beneficios son sustanciales.:el desarrollo escala mejor con más equipos, las fallas se aíslan mejor, las funciones se pueden implementar o revertir por dominio y las pilas de interfaz heredadas se pueden migrar gradualmente reemplazando una parte a la vez en lugar de reescribir la aplicación completa.

Componentes clave en una arquitectura de microfrontend

Si bien las implementaciones varían, la mayoría de las arquitecturas de microfrontend comparten algunos componentes estructurales que mantienen todo coherente.

El shell de la aplicación (o contenedor) es la columna vertebralSe encarga del diseño externo, la navegación global, la autenticación, a veces el estado global y la lógica para cargar o descargar microfrontends. En configuraciones basadas en navegador, es la página que integra todos los demás paquetes.

Cada microfrontend es un módulo autónomo que implementa una capacidad específica, como catálogo de productos, carrito de compra, perfil de usuario o panel de administración. Expone una superficie de integración (rutas, elementos personalizados, módulos remotos de federación) y oculta los detalles internos al resto del sistema.

A menudo, hay un bus de eventos o un sistema de mensajes presente para la comunicación entre microfrontends.Esto puede ser una simple abstracción sobre eventos DOM, un almacén Redux centralizado o un agente de mensajes personalizado. El objetivo es desacoplar la semántica de publicación/suscripción: un microfrontend emite eventos sin saber quién los gestiona.

Las bibliotecas compartidas albergan componentes de interfaz de usuario reutilizables, utilidades, tokens de diseño y clientes comunes.En configuraciones de monorepositorio, herramientas como Nx destacan aquí, permitiéndole definir paquetes compartidos consumidos por múltiples aplicaciones con límites impuestos y versiones consistentes.

Recopiladores y herramientas de observabilidad (por ejemplo, utilizando OpenTelemetry) agrega registros, métricas y seguimientos de todos los microfrontends, lo que hace posible diagnosticar problemas que abarcan múltiples fragmentos o servicios.

Las CDN completan el panorama en el lado de la entregaAlmacenar en caché recursos estáticos como paquetes JS, CSS e imágenes cerca de los usuarios, lo que reduce la latencia y descarga los servidores de origen. En configuraciones de microfrontend, los recursos de cada fragmento suelen alojarse en su propia ruta CDN para un almacenamiento en caché y despliegues independientes.

Arquitectura y patrones de diseño para microfrontends

Existe un amplio catálogo de patrones que se aplican específicamente a los microfrontends., generalmente definidos por cómo los compones, los implementas y los conectas.

La composición basada en componentes significa construir la interfaz de usuario a partir de componentes web o primitivos similares.Cada componente tiene una única responsabilidad, entradas y salidas claras, y puede probarse de forma aislada. Una capa de composición de nivel superior (como un shell o un marco de orquestación) organiza estos componentes en páginas completas.

El patrón de federación enfatiza la autonomía completa de las aplicacionesCada microfrontend es una aplicación independiente con su propio ciclo de vida y equipo; el shell o una puerta de enlace de API simplemente enruta las solicitudes/datos al fragmento correcto. La comunicación se realiza mediante API REST o eventos bien definidos.

El patrón de shell de aplicación es efectivamente el enfoque de “host”El shell carga microfrontends, gestiona aspectos transversales como la navegación y la seguridad, y garantiza una apariencia uniforme. Esto es muy común en configuraciones basadas en la Federación de Módulos o en una sola SPA.

Los patrones API gateway y Backend-for-Frontend (BFF) se centran en el lado del servidorUna puerta de enlace API se encuentra frente a muchos servicios backend, enrutando solicitudes y aplicando seguridad. Una BFF va más allá: cada frontend (web, móvil, IoT) puede tener su propio backend dedicado, adaptado a sus necesidades.

Los patrones de almacenamiento de datos distribuidos reconocen que diferentes microfrontends pueden administrar sus propias fuentes de datos o cachés. En el navegador, esto suele implicar el uso de claves de almacenamiento local independientes, bases de datos IndexedDB o almacenes en memoria, mientras que en el backend implica bases de datos independientes para cada microservicio.

Observabilidad, implementación independiente, escalabilidad horizontal y patrones de seguridad abordar preocupaciones operativas: cómo monitorear cada fragmento, cómo implementarlos sin interrupciones globales, cómo escalarlos bajo carga y cómo aplicar la autenticación/autorización de manera consistente.

La composición del enrutamiento y los patrones de carga diferida son fundamentales para la experiencia del usuario y el rendimiento.Un enrutador maestro decide qué microfrontend gestiona cada ruta, y cada microfrontend tiene su propio enrutador interno. La carga diferida garantiza que solo se descargue el código de los fragmentos realmente necesarios para la ruta actual.

Finalmente, los patrones de comunicación basados ​​en eventos garantizan que los microfrontends débilmente acoplados aún puedan coordinarse. a través de eventos de dominio, sin introducir dependencias directas que frustrarían el objetivo de modularidad.

Cuándo usar microfrontends (y cuándo no)

Los microfrontends brillan en aplicaciones grandes y complejas con dominios funcionales bien definidosPiense en plataformas de comercio electrónico, sistemas de gestión empresarial, portales municipales, plataformas educativas, grandes portales de salud o cualquier producto con muchos equipos trabajando en áreas funcionales separadas.

Son particularmente útiles cuando tienes varios equipos trabajando en paralelo. Que necesitan autonomía en decisiones tecnológicas, ciclos de lanzamiento y prioridades, o cuando se moderniza lentamente un frontend heredado y no se puede permitir una reescritura completa. Se puede crear un área a la vez en un nuevo microfrontend e integrarlo con el shell antiguo.

También ayudan cuando diferentes partes de la aplicación necesitan escalarse de manera diferente.Una página de inicio de sesión o de pago puede recibir mucho más tráfico que una pantalla de configuración de administración; escalar esas secciones de forma independiente puede ahorrar una gran cantidad de costos de infraestructura.

Sin embargo, los microfrontends no son un almuerzo gratis.Añaden complejidad arquitectónica, requieren una sólida coordinación en la experiencia de usuario (UX) y contratos compartidos, e introducen nuevos modos de fallo (por ejemplo, que un fragmento no se cargue). Para aplicaciones pequeñas o medianas con un solo equipo, un monolito bien estructurado suele ser más sencillo y rentable.

Los equipos también deben tener cuidado con la “anarquía del marco”Si bien es técnicamente posible que cada microfrontend utilice una pila completamente diferente, una combinación descontrolada de frameworks dificulta la contratación, el desarrollo de herramientas y la compartición de código. Un nivel razonable de alineación (por ejemplo, "somos una empresa que prioriza React, pero permitimos Angular para dominios específicos") suele funcionar mejor a largo plazo.

Los microfrontends extienden la mentalidad de los microservicios al navegador, lo que brinda a los equipos una forma de dividir grandes frontends en piezas autónomas y orientadas al dominio que pueden evolucionar, implementarse y escalar de forma independiente y, al mismo tiempo, formar una experiencia de usuario cohesiva cuando se combinan a través de un shell de aplicación, bibliotecas compartidas, federación de módulos, componentes web o marcos de orquestación como Single-SPA.