El host de microfrontends: de qué es responsable y qué no debe hacer
El host es la primera aplicación que carga el navegador y la única pieza de la que dependen todos los equipos. Mantenerlo pequeño es la decisión de diseño más importante de una plataforma de microfrontends.
El host en una frase
El host, también llamado shell, es dueño de lo que es común a todo el producto y carga todo lo demás bajo demanda.
Se carga en cada visita, y todos los remotos corren dentro de él. Un error en el host afecta a todos los equipos a la vez. Esa es la razón de las dos listas que siguen.
De qué es responsable el host
Rutas de nivel superior
El host asigna prefijos de URL a remotos. /billing/... pertenece al remoto de facturación, /catalog/... al de catálogo. El host conoce el prefijo y nada de las rutas que hay dentro. Los detalles están en Rutas entre microfrontends.
Login y sesión
El host inicia el flujo de login, mantiene la sesión y expone el usuario actual a los remotos. Los remotos consumen la sesión y nunca crean una. Mira Autenticación compartida.
Layout
El encabezado, la navegación principal, el pie y el área de contenido donde se muestra el remoto activo. Aquí también viven los controles de todo el producto: el selector de idioma, el tema, las notificaciones globales.
Carga de remotos
El host sabe dónde vive cada remoto, normalmente gracias a un manifiesto que descarga al iniciar. Carga un remoto cuando su ruta se visita por primera vez y mientras tanto muestra un estado de carga.
Fallback
Los remotos a veces no cargan. El host decide qué ve el usuario en ese caso: un panel de error en el área de contenido, una acción para reintentar y una navegación que sigue funcionando para que el usuario pueda ir a otra parte.
En Angular, cargar un remoto es una promesa dentro de una ruta lazy, así que el fallback puede ser un catch que devuelve rutas locales:
{
path: 'billing',
loadChildren: () =>
loadRemoteModule('billing', './routes')
.then(m => m.BILLING_ROUTES)
.catch(() => REMOTE_UNAVAILABLE_ROUTES)
}Infraestructura transversal
El manejador global de errores, la configuración de telemetría, el arranque de los feature flags y el locale. Se inicializan una vez y se ofrecen a los remotos mediante paquetes compartidos.
Qué no debe hacer el host
- Contener lógica de negocio. Sin pantallas de dominio y sin llamadas a APIs de facturas o pedidos. Un dashboard que mezcla datos de varias áreas es también un remoto, con su dueño.
- Conocer los internos de un remoto. Sin imports de tipos del remoto, sin conocer rutas internas, sin casos especiales por remoto en el código.
- Hacer de librería compartida. Las utilidades van en paquetes versionados. Cuando los remotos importan helpers del host, todos dependen del ciclo de publicación del host.
- Guardar estado de funcionalidades. El contenido del carrito, los filtros y los borradores de formularios pertenecen al remoto dueño, o al backend.
- Exigir una publicación para agregar o actualizar un remoto. La ubicación de los remotos y las entradas de menú vienen de configuración leída en tiempo de ejecución.
- Volverse pesado. Cada kilobyte del host se paga en cada página del producto.
Una prueba simple: si un equipo de producto necesita un cambio en el host para publicar una funcionalidad normal, el host está haciendo demasiado. Los cambios en el host deberían ser raros, y casi todos deberían ser trabajo de plataforma.
El contrato que ofrece el host
Los remotos necesitan pocas cosas del host. Escríbelas y versiónalas como una API.
| Contrato | Forma típica |
|---|---|
| Punto de montaje | Un prefijo de ruta y un área de contenido |
| Usuario actual y token | Un servicio de autenticación compartido o una función pequeña de un paquete de plataforma |
| Navegación | URLs estándar y el router compartido |
| Entradas de menú | Las declara cada remoto en el manifiesto o la configuración; las muestra el host |
| Eventos globales | Una lista corta de eventos con nombre, como cambio de usuario o cambio de idioma |
| Design system | Un rango de versiones soportado de tokens y componentes |
Todo lo que queda fuera de este contrato es privado del host. Los remotos que se meten en el DOM o en los servicios internos del host se van a romper en la siguiente publicación del host, y el equipo del host hace bien en dejar que se rompan.
Quién es dueño del host
Un equipo de plataforma pequeño. El host cambia con menos frecuencia que cualquier remoto, y sus cambios pasan una revisión más estricta, porque el radio de impacto es todo el producto. Su pipeline debería incluir un smoke test que cargue todos los remotos antes de promover una publicación.
Los equipos de producto contribuyen al host a través del equipo de plataforma, como lo harían con cualquier librería compartida. La estructura de equipos se discute en Equipos, dueños y la ley de Conway.
Checklist
- ¿Se puede agregar un remoto nuevo sin reconstruir el host?
- ¿El producto sigue siendo usable cuando un remoto no carga?
- ¿Hay alguna llamada a una API de negocio en el host? Si la hay, muévela.
- ¿El contrato entre host y remotos está escrito y versionado?
- ¿Cada publicación del host corre un smoke test contra todos los remotos?
- ¿Se hace seguimiento del tamaño del bundle del host a lo largo del tiempo?
Más en esta sección
- Rutas entre microfrontends: dueños de rutas, deep links y contrato de navegación
- Cómo compartir login y sesión entre microfrontends
- Cómo se comunican los microfrontends y qué evitar
- Dependencias compartidas y versiones en microfrontends
¿Planeas una migración o una plataforma de microfrontends?
En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.
Escríbeme por LinkedIn