Skip to main content

🚀 Guía mínima: subir un Remote en la arquitectura Microfrontend (ALPURA)

Objetivo: que un dev pueda levantar local, generar build, publicar y registrar su remote para que el Shell/Host lo cargue dinámicamente.

1) Prerrequisitos​

  • Versión de Angular requerida:
    • Versión: 19.0.0
  • Node / NPM según el estándar del proyecto:
    • Node.js: Entorno de ejecución para JavaScript del lado del servidor.
      • Versión: 20.19.0 o superior
    • npm: Gestor de paquetes para Node.js.
      • Versión: 9.6.7 o superior
  • Acceso al registry/hosting donde se publican los assets del remote (UAT/Prod).
  • Variables de entorno / permisos de CI/CD listos.

De los 2 últimos puntos favor de pedir accesos a Alejandro Hernández Roque (alejandro.roque@alpura.com).

2) Estructura esperada del Remote​

Tu remote debe exponer:

  • Un remoteName estable (no cambiarlo después).
  • Un remoteEntry accesible por URL (Module Federation clásico)
  • Una ruta/entry de exposición (lo que el Host cargará).

En nuestra arquitectura el Host genera rutas dinámicas (menú/config) y monta el remote dentro de un wrapper tipo ContentLayoutComponent.

El archivo remoteEntry local se genera al levantar el ambiente y para obtenerlo de UAT o PROD se necesita solicitarlo a Alejandro Hernández Roque (alejandro.roque@alpura.com).

3) Configuración de Federation (mínimo indispensable)​

3.1 Define el remoteName​

Mantén el nombre consistente.

Ejemplo (conceptual):

  • remoteName: alpura-mfe-mi-remote

El archivo donde definimos el remoteName es en webpack.config.js que debera estar en la raíz del proyecto.

4) Correr el Remote en local​

Desde el repo del remote:

ng serve

5) Construir el build del Remote en local​

Desde el repo del remote:

npm run build

Es muy importante construir el build localmente, para detectar posibles errores a la hora de subir el codigo a UAT o PROD.

6) Environments requeridos (LOCAL / UAT / PROD)​

Obligatorio: el remote debe incluir environments para local, uat y prod, usando fileReplacements en angular.json.

6.1 Archivos mínimos esperados​

  • src/environments/environment.ts (local)
  • src/environments/environment.uat.ts (uat)
  • src/environments/environment.prod.ts (prod)

6.2 Estructura mínima del environment​

Usa esta estructura (misma interfaz/shape en los 3 archivos):

// This file can be replaced during build by using the `fileReplacements` array.
// `ng build` replaces `environment.ts` with `environment.prod.ts`.
// The list of file replacements can be found in `angular.json`.

export const environment = {
  production: false,
  apiBaseUrl: "https://hub-apg-uat.alpura.com:8243",
  apiVersion: "v1",
  nameMFE: "CRM Ranchos",
};

6.3 Reglas por ambiente (mínimas)​

LOCAL (environment.ts)​

  • production: false

  • apiBaseUrl: URL local o la que aplique para desarrollo (si apuntan a UAT también es válido si así está el estándar del equipo)

  • apiVersion: 'v1'

  • nameMFE: Nombre del remote (para temas de MATOMO) ejemplo: mi-app

UAT (environment.uat.ts)​

  • production: false (o según estándar del equipo, pero mantenerlo consistente)

  • apiBaseUrl: https://hub-apg-uat.alpura.com:8243

  • apiVersion: 'v1'

  • nameMFE: Nombre del remote (para temas de MATOMO) ejemplo: mi-app

PROD (environment.prod.ts)​

  • production: true

  • apiBaseUrl: URL de PROD (la definida por la plataforma)

  • apiVersion: 'v1'

  • nameMFE: Nombre del remote (para temas de MATOMO) ejemplo: mi-app

7) webpack.config.js: configurar exposes (qué expone tu Remote al Host)​

En Module Federation clásico, tu webpack.config.js define qué piezas del remote (componentes/módulos) serán consumibles por el Host.

Ejemplo​

exposes: {
  './TipoPersonaComponent': './src/app/features/tipo-persona/views/tipo-persona.component.ts',
},

¿Qué significa?​

  • exposes es un mapa: alias público → ruta real del archivo en tu repo

Alias público (clave):

  • './TipoPersonaComponent' = el nombre con el que el Host lo va a solicitar

Ruta real (valor):

  • './src/app/features/tipo-persona/views/tipo-persona.component.ts' = el archivo que realmente expones

¿Por qué es importante?​

  • Si el Host intenta cargar ./TipoPersonaComponent pero no existe en exposes, tendrás errores al montar el remote.
  • Si mueves el archivo y no actualizas la ruta en exposes, el build puede pasar, pero el runtime falla.

Buenas prácticas mínimas​

  • No renombres el alias público sin coordinar con el Host.
  • Expón solo lo que necesitas (evitar exponer “todo”).
  • Valida E2E desde el Host después de cambios en exposes.