Desarrollo local con microfrontends

Los desarrolladores deberían poder trabajar en un remoto sin levantar toda la plataforma. Un buen desarrollo local significa un comando, un arranque rápido y un ambiente realista.

El objetivo

Una desarrolladora del equipo de pedidos cambia pedidos. Su máquina debería correr el remoto de pedidos y lo menos posible de todo lo demás. Si trabajar en un área exige clonar y levantar todos los repositorios, la plataforma volvió el trabajo diario más lento de lo que era en el monolito.

Hay dos modos útiles, y una plataforma madura ofrece ambos.

Modo 1: Independiente, con un mock del host

El remoto corre solo, como una aplicación normal. Un shell de desarrollo delgado reemplaza al host real y entrega lo que promete el contrato:

• Una sesión falsa con usuario, roles e idioma configurables.
• Un layout mínimo, para que el remoto se renderice en tamaños realistas.
• El tema del design system.
• Stubs de las APIs de navegación y de eventos, con logs para que quien desarrolla vea lo que envía el remoto.

El equipo de plataforma debería publicar este shell de desarrollo como un paquete, versionado junto con el contrato. Si cada equipo escribe su propio mock, los mocks se alejan del host real y los bugs aparecen solo después de un despliegue.

El modo independiente es el más rápido, y es el correcto para la mayor parte del trabajo diario y para las pruebas del propio remoto. Su límite es el realismo: no muestra nada de cómo se comporta el remoto junto a sus vecinos reales.

Modo 2: Remoto local contra versiones desplegadas del resto

Aquí se corre en local solo el remoto propio. El host y los demás remotos vienen de un ambiente desplegado. Así se ve la integración real sin el costo de levantar todo.

Formas comunes de hacerlo:

• Host local con un manifiesto de desarrollo. El host corre en local con un manifiesto en el que cada remoto apunta al ambiente de desarrollo desplegado, salvo el que se está cambiando, que apunta a localhost.
• Host desplegado con una sobrescritura. Se abre el host desplegado de un ambiente de desarrollo y se le indica que cargue un remoto desde localhost. Las plataformas basadas en import maps suelen usar la librería import-map-overrides para esto. Un host propio puede soportar la misma idea con un valor en local storage que solo respetan los builds que no son de producción.
• Herramientas del workspace. En un workspace de Nx con Module Federation, el comando serve del host acepta una lista de remotos para correr en modo desarrollo y sirve los demás como builds estáticos.

Hay dos condiciones. El remoto local debe permitir peticiones de origen cruzado desde el origen del host. Y sus versiones de dependencias compartidas deben ser compatibles con las desplegadas: una rama local que sube la versión del framework puede no cargar dentro de un host que sigue en la versión anterior, o cargar una segunda copia del framework.

Configuración de ambientes

La configuración es donde suelen romperse los ambientes locales.

• Usa configuración en ejecución. Carga las direcciones de las APIs y los feature flags desde un archivo de configuración pequeño al arrancar, y evita dejarlos fijos en el build. Así el mismo build corre en local, en pruebas y en producción.
• Usa un proxy para las llamadas a APIs. El servidor de desarrollo puede reenviar las peticiones a un backend de desarrollo compartido, lo que evita problemas de origen cruzado. Angular CLI lo soporta con un archivo de configuración de proxy.
• Planifica la autenticación para localhost. El proveedor de identidad necesita un cliente de desarrollo que acepte direcciones de redirección locales. En modo independiente, la sesión simulada evita el login por completo.
• Simula el backend cuando haga falta. Una herramienta como Mock Service Worker permite que un remoto corra sin backend, lo que ayuda en el trabajo temprano y da pruebas estables.

Mantener rápido el arranque

La velocidad decide si las personas siguen el flujo previsto o inventan atajos.

• Corre solo lo que cambias. Todo lo demás viene ya compilado, desde un ambiente desplegado o desde una caché.
• Prefiere builders rápidos. Las versiones recientes de Angular compilan con esbuild, y Native Federation funciona sobre ese builder. Las diferencias se explican en Module Federation vs Native Federation.
• Espera límites en el hot reload. El reemplazo de módulos en caliente entre módulos federados es menos confiable que en una sola app. Recargar por completo un remoto pequeño suele ser suficientemente rápido.

Un comando y un documento corto

El repositorio de cada remoto debería ofrecer:

1. Un comando que inicia el modo independiente.
2. Un comando que inicia el remoto contra el ambiente de desarrollo.
3. Un README corto: requisitos, los dos comandos, cómo iniciar sesión y cómo elegir el usuario simulado.

Una persona nueva debería poder correr su remoto el primer día. Si toma más tiempo, el equipo de plataforma tiene trabajo pendiente.

Más en esta sección

• Qué son los microfrontends: guía para quienes deciden
• Cuándo valen la pena los microfrontends y cuándo no
• Module Federation vs Native Federation en Angular
• single-spa vs Module Federation: cómo elegir