Arquitectura
4 aplicaciones React independientes integradas en tiempo de ejecución. El Shell orquesta, los remotes exponen.
Shell (Host) :3000
Orquestador principal. React Router + React.lazy + ErrorBoundary. Carga cada MFE bajo demanda cuando el usuario navega.
Catalog :3001
Lista de productos. Expone CatalogApp vía remoteEntry.js. Despacha eventos de "add-to-cart".
Product :3002
Detalle de producto con descripción y botón de compra. Independiente del catálogo.
Cart :3003
Carrito con persistencia en localStorage. Controles de cantidad y eliminación.
Module Federation
Cada MFE genera un remoteEntry.js. El Shell los consume en runtime sin conocer su código en build time.
Webpack 5 Module Federation permite que aplicaciones independientes compartan código en tiempo de ejecución. Cada remote expone módulos, el host los consume vía import dinámico, y las dependencias compartidas (React, ReactDOM, Router) se negocian como singletons para evitar duplicación.
El patrón de entrada asíncrona (index.js → bootstrap.js) es clave: permite que Federation negocie las dependencias compartidas antes de que cualquier código de la aplicación se ejecute.
Comunicación entre MFEs
Sin estado global compartido. CustomEvents + localStorage — APIs nativas del navegador.
Cuando el usuario agrega un producto al carrito, el MFE de catálogo (o producto) despacha un CustomEvent y escribe en localStorage. Si el carrito está montado, su listener actualiza el estado en vivo. Si no está montado, al navegar a /cart lee el estado persistido.
Este enfoque es resiliente: funciona aunque un MFE no esté disponible, persiste entre recargas, y no introduce dependencias adicionales. El badge del navbar escucha los mismos eventos para actualizarse en tiempo real.
Decisiones de arquitectura
Cuándo sí usar MFEs
Equipos grandes (3+) trabajando en el mismo producto. Necesidad de despliegues independientes. Secciones claramente separables.
Cuándo no
Equipos pequeños. Apps simples. Cuando la velocidad de desarrollo inicial importa más que la independencia de despliegue.
Aislamiento de fallos
ErrorBoundary por cada remote. Un MFE caído no tumba la app — el usuario puede seguir navegando.
Consistencia visual
Design tokens compartidos vía CSS custom properties. Sin librería de componentes compartida — disciplina sobre tooling.
Stack
Por qué lo construí
En mi trabajo he visto equipos considerar microfrontends sin entender los trade-offs reales. Quería construir uno de principio a fin para tener una opinión informada: cuándo vale la pena la complejidad operacional y cuándo es over-engineering.
La conclusión: Module Federation funciona bien para equipos grandes con necesidad real de despliegue independiente. Para equipos pequeños, el overhead no se justifica. Pero el ejercicio de pensar en comunicación desacoplada, aislamiento de fallos y contratos entre módulos aplica a cualquier arquitectura frontend — no solo a microfrontends.
Si te interesa conversar sobre este proyecto o sobre arquitectura frontend en general, escríbeme.