Los microfrontends dividen una aplicación web en piezas independientes que distintos equipos programan, prueban y publican sin pisarse. Durante años se vendieron como la respuesta natural a un frontend monolítico que frenaba a toda la empresa, desde un marketplace de moda hasta una aseguradora con varias líneas de producto. La promesa sigue siendo la misma, pero la forma de aplicarla ha cambiado mucho desde que la técnica se popularizó. Esta pieza es para responsables de marketing que piden plataformas que escalen y para los equipos técnicos que deciden cómo construirlas: qué datos hay detrás de la moda, cuándo compensa de verdad y qué cuesta mantenerla.
Los microfrontends compensan cuando varios equipos —normalmente cuatro o más— despliegan la misma plataforma con calendarios distintos y necesitan aislar fallos entre secciones. Con un solo equipo o menos de diez desarrolladores, un monolito bien modularizado resuelve lo mismo con menos piezas que mantener.
El origen de los microfrontends en los microservicios
El término apareció en el Technology Radar de ThoughtWorks a finales de 2016, cuando varios equipos ya aplicaban microservicios en el backend y empezaron a preguntarse por qué el frontend seguía siendo un único proyecto gigante. La idea la desarrolló después el consultor Cam Jackson en un artículo publicado en el blog de Martin Fowler, que sigue siendo la referencia técnica más citada sobre el tema.
La analogía es directa: de la misma forma que los microservicios rompen un backend monolítico en piezas desplegables por separado, los microfrontends hacen lo mismo con la interfaz. Cada equipo es dueño de una sección completa —el catálogo, el checkout, el panel de facturación— desde el código hasta el despliegue, sin depender de que otro equipo libere su parte primero.
Un microfrontend es una aplicación frontend desplegable de forma independiente que se compone, junto con otras, en una experiencia mayor: la definición que fijó ThoughtWorks y que sigue usando el sector.
El equipo que de verdad necesita microfrontends
La pregunta que importa no es técnica, es organizativa: ¿cuántos equipos trabajan hoy sobre la misma plataforma y con qué calendario publican? Por debajo de cuatro equipos independientes, orquestar builds y despliegues separados suele costar más de lo que ahorra. Conviene valorarlo con una consultoría de sistemas IT antes de comprometer meses en una migración de arquitectura.
Cuatro señales de que toca dividir el frontend
Hay patrones que se repiten en las empresas donde la división funciona. El primero es tener diez o más desarrolladores en el mismo repositorio de frontend, con colas de revisión que alargan cada entrega. El segundo es que distintas secciones pertenezcan a negocios distintos: un fabricante industrial del Vallès que vende maquinaria y gestiona, con otro equipo y otro ritmo, un portal de recambios. El tercero es necesitar desplegar una sección varias veces al día sin esperar al resto del sitio. El cuarto es migrar un sistema heredado sección a sección, en lugar de de golpe.
Cuando el monolito sigue siendo la opción correcta
Un equipo de seis o siete desarrolladores que construye el portal de un banco regional o la tienda online de un distribuidor rara vez necesita esta arquitectura: puede coordinarse en una reunión diaria y desplegar el frontend entero sin pisarse. Dividir la aplicación ahí solo añade versionado y lógica de respaldo que nadie agradece. El informe State of Frontend 2024, con más de 3.700 desarrolladores encuestados en 125 países, recoge ese giro: el uso de microfrontends cayó del 75,4% en 2022 al 23,6% en 2024, y buena parte del descenso corresponde a equipos que probaron la arquitectura sin tener el problema que la justifica.
Module Federation, la pieza técnica que lo sostiene
De las empresas que sí usan microfrontends, el 51,8% recurre a Module Federation, la función de Webpack 5 que permite a distintos proyectos compartir código en tiempo de ejecución sin empaquetarlo todo junto en el build. Un 35,5% usa Single-SPA, un framework más ligero pensado para que convivan varios frameworks de frontend a la vez en la misma página.
Module Federation resuelve el problema concreto que hace viable la arquitectura: cada equipo publica su parte como un módulo remoto, y la aplicación principal lo carga en el navegador del usuario sin necesitar un redeploy completo. Lo que antes exigía coordinar una ventana de despliegue conjunta entre varios equipos —habitual en un grupo de medios con secciones de vídeo, suscripción y comentarios gestionadas por equipos distintos— pasa a resolverse con cada equipo publicando a su ritmo.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Lo que gana y pierde un frontend fragmentado
Repartir la interfaz en piezas independientes cambia el reparto de riesgos y de trabajo dentro del equipo técnico. No es una mejora neta: se ganan algunas cosas y se pierden otras, y conviene mirarlas juntas antes de decidir.
- Cada equipo despliega su sección sin esperar turno, lo que acorta el tiempo entre una decisión de producto y su publicación.
- Un fallo en una sección —el buscador de un ecommerce, por ejemplo— no tiene por qué tumbar el checkout si están bien aislados.
- Permite usar tecnologías distintas en secciones distintas, útil cuando una aseguradora hereda un panel antiguo y construye uno nuevo al lado.
- El peso total que descarga el navegador suele crecer, porque cada pieza carga sus propias dependencias si no se comparten bien.
- Mantener una experiencia visual coherente entre secciones hechas por equipos distintos exige un sistema de diseño compartido y alguien que lo vigile.
- Depurar un fallo que cruza dos microfrontends obliga a mirar dos repositorios, dos pipelines y, a veces, dos frameworks distintos.
Alternativas al frontend dividido en equipos independientes
La caída de adopción no dejó un vacío: lo ocupan técnicas que dan parte de los mismos beneficios con menos piezas que mantener. El renderizado en servidor y la generación estática resuelven el problema de rendimiento que antes se atribuía solo a la fragmentación, y los componentes de servidor permiten que distintas partes de una misma aplicación se actualicen con independencia sin necesitar remotos separados. En este blog ya hemos explicado cómo los Web Components ofrecen otra vía: encapsular una sección en un componente estándar del navegador, sin depender de que toda la plataforma use el mismo framework.
Para una cadena de clínicas con un portal de citas y una web corporativa separadas, por ejemplo, suele bastar un buen sistema de componentes compartido entre ambas; no hace falta desplegar cada sección como una aplicación independiente. La decisión correcta depende de cuántos equipos hay detrás, no de cuánto tráfico mueve la plataforma.
Costes ocultos en el presupuesto de microfrontends
El coste que casi nunca entra en la estimación inicial es el de mantener la infraestructura compartida: el catálogo de dependencias, el sistema de diseño común y el pipeline que valida que los remotos siguen siendo compatibles entre versiones. Si la plataforma nace como un desarrollo de software a medida, ese coste hay que presupuestarlo desde el primer sprint, no descubrirlo a mitad de proyecto.
La curva de aprendizaje que retrasa el primer release
Module Federation 2.0, la revisión que resolvió buena parte de los problemas de la primera versión, añadió seguridad de tipos entre remotos, un protocolo de manifiesto y plugins de runtime para gestionar versiones y mecanismos de respaldo. Son mejoras reales, pero cada una añade un concepto nuevo que el equipo tiene que aprender antes de publicar la primera sección en producción. En equipos que nunca han tocado esta arquitectura, ese aprendizaje suele retrasar el primer despliegue varias semanas frente a seguir con el monolito, un plazo que pocas empresas presupuestan cuando aprueban el proyecto.
Preguntas frecuentes sobre microfrontends
¿Qué diferencia hay entre microfrontends y microservicios?
Los microservicios dividen la lógica de negocio en el backend; los microfrontends hacen lo mismo con la interfaz que ve el usuario. Pueden combinarse —cada microfrontend puede consumir su propio microservicio— pero son decisiones independientes: cabe un backend de microservicios con un frontend monolítico, y al revés.
¿Cuántos equipos hacen falta para que compensen?
La referencia habitual son cuatro equipos o más trabajando sobre la misma plataforma con calendarios de despliegue distintos. Por debajo de ese número, la complejidad añadida —versionado, manifiestos, sistema de diseño compartido— suele superar el beneficio de desplegar por separado.
¿Module Federation es la única forma de implementarlos?
No. Es la más usada, con el 51,8% según el informe State of Frontend 2024, pero Single-SPA, Web Components y la composición en el servidor también integran piezas independientes. La elección depende de los frameworks que ya usa cada equipo.
¿Por qué ha caído tanto su adopción desde 2022?
Porque muchos equipos la adoptaron sin tener el problema organizativo que la justifica: pocos desarrolladores, un solo equipo, un único calendario de despliegue. El informe de 2024 sitúa el uso en el 23,6%, frente al 75,4% de 2022.
