DEV Community: Michael Cervera Cobeñas

Microfrontends con Angular y Native Federation: lo que aprendí llevando más de 15 módulos a producción

Michael Cervera Cobeñas — Fri, 16 Oct 2026 20:04:14 +0000

Hace unos meses me tocó llevar una plataforma corporativa a una arquitectura de microfrontends: un portal que carga más de 15 módulos, cada uno con su propio repositorio, su propio equipo y su propio despliegue. Hoy esos módulos salen a producción por separado, sin coordinar ventanas de despliegue entre equipos.

No voy a explicar qué es un microfrontend, de eso ya hay bastante escrito. Quiero contar lo que no sale en los tutoriales, lo que solo aparece cuando el segundo, el quinto y el décimo módulo ya están en producción.

Primero: cuándo NO usar microfrontends

Empiezo por aquí porque es la pregunta que más me hacen y la respuesta honesta es "casi nunca al inicio".

Te conviene	No te conviene
Varios equipos que necesitan desplegar sin esperarse	Un solo equipo trabajando en un solo producto
Dominios de negocio claramente separados (ventas, calidad, RRHH)	Pantallas que comparten casi todo el estado
Módulos que crecen a ritmos distintos	Un producto que todavía está buscando su forma
Una plataforma que va a vivir años	Un MVP que tiene que salir en semanas

Si estás en la columna de la derecha, un monolito bien modularizado te da el 80 % del beneficio con el 20 % del costo. Los microfrontends son, sobre todo, una decisión de organización. Pagan cuando el cuello de botella es la coordinación entre equipos, no la calidad del código.

La arquitectura, en una imagen

                    ┌──────────────────────────────┐
   usuario ───────▶│ HOST (portal) │
                    │ · login único (OIDC) │
                    │ · menú según permisos │
                    │ · lee el manifiesto │
                    └──────────────┬───────────────┘
                                   │ carga en tiempo de ejecución
            ┌──────────────────────┼──────────────────────┐
            ▼ ▼ ▼
     remoteEntry.json remoteEntry.json remoteEntry.json
     ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
     │ Ventas │ │ Calidad │ │ RRHH │
     │ repo propio │ │ repo propio │ │ repo propio │
     │ deploy │ │ deploy │ │ deploy │
     │ propio │ │ propio │ │ propio │
     └──────────────┘ └──────────────┘ └──────────────┘

El stack es Angular con Native Federation (@angular-architects/native-federation). Es el sucesor de Module Federation para el builder moderno de Angular basado en esbuild: en lugar de depender de webpack, usa los estándares del navegador (módulos ES e import maps).

El host no conoce a los módulos en tiempo de compilación. Los descubre al arrancar, desde un manifiesto:

// federation.manifest.json (uno por ambiente)
{
  "ventas": "https://ventas.ejemplo.com/remoteEntry.json",
  "calidad": "https://calidad.ejemplo.com/remoteEntry.json"
}

// main.ts del host
initFederation('federation.manifest.json')
  .then(() => import('./bootstrap'));

// rutas del host
{
  path: 'ventas',
  loadChildren: () =>
    loadRemoteModule({ remoteName: 'ventas', exposedModule: './Routes' })
      .then(m => m.routes)
}

Hasta aquí es lo que trae cualquier tutorial. Lo que sigue lo aprendí en producción.

Lo que rompe en producción (y cómo lo resolví)

1. Las rutas absolutas dentro de un módulo

Un módulo se desarrolla solo, en su propio puerto, donde /detalle/42 funciona perfecto. Embebido en el portal, ese módulo vive bajo /ventas, y /detalle/42 manda al usuario a una ruta que no existe.

La regla: dentro de un módulo, toda navegación es relativa. routerLink="detalle/42" y router.navigate(['detalle', id], { relativeTo: route }). Es una línea en la guía del equipo y una revisión en cada pull request, pero ahorra el bug más repetido de toda la plataforma.

2. El CORS de `remoteEntry.json`

El host pide el remoteEntry.json y los chunks de cada módulo desde otro dominio. Si el servidor del módulo no responde con Access-Control-Allow-Origin, el navegador bloquea la carga y el usuario ve una pantalla en blanco sin ningún error útil en la interfaz.

La regla: el CORS de los archivos estáticos del módulo es parte de la plantilla del proyecto, no algo que cada equipo descubre por su cuenta. Todo módulo nuevo nace con la configuración de su servidor web ya resuelta.

3. La caché que esconde la versión nueva

Despliegas, todo sale en verde, y el usuario sigue viendo la versión anterior. El culpable casi siempre es remoteEntry.json: es el único archivo cuyo nombre no cambia entre versiones, así que si el navegador o un CDN lo guarda, apunta a chunks viejos.

La regla: remoteEntry.json se sirve sin caché; los chunks, que llevan un hash en el nombre, se pueden cachear para siempre. Así cada despliegue llega al usuario en la siguiente carga, sin pedirle a nadie que borre su caché.

4. Un manifiesto por ambiente… y la vez que se mezclaron

Cada ambiente (pruebas y producción) tiene su propio manifiesto con las URLs de sus módulos. Una vez, una construcción manual horneó los valores por defecto y el portal de producción terminó cargando módulos de pruebas. El síntoma fue un error de CORS; la causa, un ambiente mezclado.

La regla: el pipeline valida, antes de construir, que todas las URLs correspondan al ambiente destino, y aborta si no. Desde entonces ese error ya no puede repetirse, porque el pipeline no lo deja pasar.

5. Una sola versión del Design System en todos los módulos

Los módulos comparten librerías: Angular, el router y el Design System propio que usan 17 aplicaciones. Native Federation las comparte como singleton, pero si un módulo trae otra versión del Design System, el portal muestra dos estilos distintos en la misma pantalla o, peor, componentes que se rompen al navegar entre módulos.

La regla: cada cambio en el Design System se publica como paquete versionado y se actualiza en todos los módulos a la vez, no solo en el que lo necesitaba. Y no basta con subir el rango en el package.json: si la imagen se construye con npm ci, manda el lockfile, así que hay que reinstalar y versionar el lock también.

6. Un módulo en el menú que todavía no existe

El portal arma su menú desde un catálogo de módulos. Registrar un módulo antes de que esté desplegado en todos los ambientes hace que el portal intente cargar un remoteEntry.json que no existe, y esa ruta queda rota.

La regla: cada entrada del catálogo tiene un indicador de disponibilidad. El módulo aparece en el menú con una página de "próximamente" hasta que su servicio existe donde corre el portal.

El login: uno solo, en el host

La decisión que más simplificó todo: solo el host autentica. El portal maneja el inicio de sesión con OIDC (Keycloak) y los módulos reciben el token ya resuelto. Ningún módulo define su propia autorización ni su propio login.

Eso tiene dos efectos. Para el usuario, un solo inicio de sesión para toda la plataforma. Para los equipos, un módulo nuevo no empieza escribiendo pantallas de login, sino pantallas de negocio. Los permisos viajan en el token y el menú se arma según ellos.

Si cada módulo resuelve la seguridad a su manera, tienes tantos modelos de seguridad como módulos. Centralizarla es la única forma de poder auditarla.

Qué haría distinto si empezara hoy

El Design System antes que el segundo módulo. Cada componente que un equipo construye "mientras tanto" es un componente que después hay que migrar.
Las barreras del pipeline desde el día uno. La validación de ambientes la agregué después de un incidente. Pudo estar desde el inicio.
Automatizar la actualización del Design System. Actualizar una librería en más de 15 repositorios a mano no escala: es exactamente el tipo de tarea que debe hacer un script, no una persona.
Una plantilla de módulo. CORS, rutas relativas, configuración de federación y pipeline listos al crear el repositorio. Cada regla de este artículo debería ser un archivo de la plantilla, no un párrafo de la guía.

Para cerrar

Los microfrontends funcionan cuando resuelven un problema de organización: equipos que necesitan avanzar sin esperarse. La parte técnica —federación, manifiestos, rutas— se resuelve en una semana. Lo difícil es todo lo demás: que cada regla quede escrita, que las que importan se conviertan en barreras automáticas y que cualquier persona del equipo pueda sostener la plataforma con lo que está documentado.

Si estás evaluando microfrontends para tu equipo o ya estás peleando con alguno de estos problemas, escríbeme por LinkedIn. Me interesa saber cómo lo están resolviendo otros.

Publicado originalmente en mi blog.

SAP Business One con una sola puerta: cómo lo integré en 17 aplicaciones sin que ninguna le hable directo

Michael Cervera Cobeñas — Sat, 10 Oct 2026 22:23:48 +0000

Cuando una empresa usa SAP Business One y empieza a construir sus propias aplicaciones, lo primero que pasa es que cada una se conecta a SAP por su cuenta. La de ventas consulta clientes, la de compras consulta proveedores, la de recursos humanos consulta empleados. Cada una con sus credenciales, sus consultas y su forma de manejar los errores.

Con dos aplicaciones se puede vivir así. Con diecisiete, no. En la plataforma que lidero ninguna aplicación habla con SAP directamente, y cuento cómo está armado y qué fui aprendiendo al integrarlo.

Una sola puerta hacia SAP

Toda la comunicación con SAP pasa por un gateway: un servicio en .NET que es el único que tiene las credenciales de SAP. Por dentro usa dos caminos:

El Service Layer , la API oficial de SAP Business One, para crear documentos y para las lecturas estándar.
Lectura directa a HANA , con procedimientos almacenados, para las consultas pesadas que por Service Layer tomarían muchas llamadas.

Y tampoco las aplicaciones llaman al gateway. Solo lo llama el backend del portal, y cada módulo le pide los datos al portal:

 módulo (ventas, compras, rrhh…)
        │ token del usuario
        ▼
 backend del portal ──── tablas espejo (maestros)
        │ mismo token
        ▼
 gateway SAP (único con credenciales)
        │
        ▼
 SAP Business One (Service Layer + HANA)

El token del usuario viaja en cada salto. Así el gateway sabe quién pidió cada cosa, y ningún módulo necesita una cuenta de servicio de SAP.

Los maestros se copian, no se consultan

La decisión que más ordenó todo fue esta: los maestros de SAP (clientes, empleados, artículos, proveedores, cuentas contables, departamentos) se sincronizan en la base de datos del portal como tablas espejo. Los módulos leen esas tablas a través de la API del portal. Nunca consultan SAP en vivo para un maestro.

La sincronización tiene un solo punto de entrada por maestro, un POST /sync que es lo único que llama al gateway. Se dispara de dos formas:

Con un botón "Sincronizar con SAP" en la configuración del portal, solo para administradores.
Con una tarea programada todas las madrugadas, que corre todos los maestros en secuencia. Si uno falla, los demás siguen.

Por dentro es un upsert por lotes, y lo que desaparece de SAP se marca como inactivo en vez de borrarse, porque puede haber registros en el portal que todavía apuntan a él. La corrida completa, unos 35 mil registros, toma menos de un minuto.

¿Por qué copiar en lugar de consultar?

Velocidad. Un buscador de clientes no puede esperar a SAP en cada tecla.
Disponibilidad. Si SAP está en mantenimiento, el portal sigue funcionando con los datos de la noche anterior.
Un solo lugar para corregir. Si cambia cómo se lee un maestro, se cambia en la sincronización y todos los módulos lo reciben igual.

En vivo solo va lo que tiene que estar al segundo: el stock, el costo de un artículo, el tipo de cambio y la creación de documentos.

Para que esto se mantenga, quedó escrito como regla, con el patrón paso a paso para agregar un maestro nuevo: el endpoint en el gateway, la tabla espejo y su sincronización en el portal, la pantalla con el botón, y el módulo leyendo del portal. Cualquiera del equipo puede agregar uno siguiendo esos pasos.

Lo que aprendí integrando

El Service Layer corta en 20 sin avisar

Una consulta pedía 100 órdenes y llegaban 20. El Service Layer pagina de a 20 por defecto y deja el resto detrás de un @odata.nextLink. No da error ni advertencia, y el count de la respuesta sí trae el total real. Lo descubrimos porque un usuario decía que sus órdenes no estaban en SAP, cuando en realidad estaban en la página dos.

Hay que pedir el tamaño de página explícitamente (la cabecera Prefer: odata.maxpagesize) o seguir el nextLink. Y del lado de quien pagina, la condición de corte tiene que ser el count, no "el lote vino más chico de lo que pedí", porque con este comportamiento eso corta en la primera vuelta.

`DocTotal` no está en la moneda del documento

En los documentos de SAP Business One, DocTotal es el total en moneda local. DocCurrency dice en qué moneda se emitió. Mostrar DocTotal con el símbolo de DocCurrency hacía que una orden en dólares apareciera con el monto en soles, o sea más del triple.

El importe en la moneda del documento es DocTotalFc, pero cuando el documento está en moneda local SAP lo deja en 0, y un 0 se puede leer como "cero dólares". Por eso el gateway lo publica como null en ese caso, y quien lo consume usa DocTotal cuando no hay otro. Lo llamamos "moneda extranjera" y no "dólares", porque una parte de las compras están en euros.

Hubo un segundo tropiezo con esto mismo: el Service Layer solo devuelve los campos que pides en el $select. Agregamos DocTotalFc al modelo pero no a la lista de campos de la consulta, así que llegaba vacío siempre. Eso no lo detecta el compilador, solo se ve llamando a SAP.

Un error de validación disfrazado de caída

Una alerta de errores 5xx sonó un día por varios 502 seguidos. No era SAP caído: alguien había pedido un costeo sin elegir cliente, el gateway respondió 400 diciendo que faltaba el cliente, y la función que hacía las lecturas convertía cualquier respuesta no exitosa en 502. Las escrituras sí propagaban bien el 400, las lecturas no.

Ese error tenía dos costos: el usuario veía "SAP no responde" cuando el problema era un campo vacío, y la métrica que dispara las alertas se llenaba de falsos 5xx. Ahora las lecturas propagan los 400, 409 y 422 tal cual, con el mensaje del backend.

El SQL de SAP también es código

Los procedimientos almacenados que lee el gateway se crearon directamente en HANA y no estaban en ningún repositorio. Y el mapeo de sus resultados es tolerante a propósito: busca las columnas por nombre, y si una columna cambia de nombre, el campo llega null o 0 sin ningún error.

O sea, alguien podía cambiar un procedimiento y una pantalla empezaba a mostrar ceros sin que nada fallara. La regla que acordamos: el SQL vive con el código que se rompe si cambia. Cada procedimiento que llama el gateway se versiona en su repositorio, en el mismo cambio que el código que lo lee.

Qué haría distinto si empezara hoy

Versionar el SQL de SAP desde el primer procedimiento. Recuperarlo después, cuando ya hay decenas en uso, es arqueología.
Pruebas contra una copia de la compañía. Los dos tropiezos del DocTotal se ven recién llamando a SAP. Una prueba que corra contra una base de respaldo los habría atrapado antes de producción.
Una sola función de paginación en el gateway. El corte en 20 apareció en varias consultas a la vez porque cada una paginaba a su manera.
La moneda explícita en cada monto. Ningún campo de dinero sin su moneda al lado, aunque parezca obvio.

Si estás por integrar con SAP Business One

Antes de escribir la primera consulta, decide quién es el único que habla con SAP. Si cada aplicación se conecta por su cuenta, después cuesta mucho juntar todo en un solo lugar. Y separa desde el inicio lo que se copia (los maestros) de lo que va en vivo: esa decisión define cuánto depende tu plataforma de que SAP esté disponible.

Si estás integrando con SAP Business One, escríbeme por LinkedIn. Me interesa saber cómo lo resolvieron otros equipos, sobre todo con el Service Layer.

Publicado originalmente en mi blog.

DEV Community: Michael Cervera Cobeñas

Microfrontends con Angular y Native Federation: lo que aprendí llevando más de 15 módulos a producción

Primero: cuándo NO usar microfrontends

La arquitectura, en una imagen

Lo que rompe en producción (y cómo lo resolví)

1. Las rutas absolutas dentro de un módulo

2. El CORS de remoteEntry.json

3. La caché que esconde la versión nueva

4. Un manifiesto por ambiente… y la vez que se mezclaron

5. Una sola versión del Design System en todos los módulos

6. Un módulo en el menú que todavía no existe

El login: uno solo, en el host

Qué haría distinto si empezara hoy

Para cerrar

SAP Business One con una sola puerta: cómo lo integré en 17 aplicaciones sin que ninguna le hable directo

Una sola puerta hacia SAP

Los maestros se copian, no se consultan

Lo que aprendí integrando

El Service Layer corta en 20 sin avisar

DocTotal no está en la moneda del documento

Un error de validación disfrazado de caída

El SQL de SAP también es código

Qué haría distinto si empezara hoy

Si estás por integrar con SAP Business One

2. El CORS de `remoteEntry.json`

`DocTotal` no está en la moneda del documento