DEV Community: Miguel Quispe

MicroFrontend: integración sin host — prácticas y configuración

Miguel Quispe — Mon, 02 Jun 2025 17:58:16 +0000

En algunos proyectos, los módulos se desarrollan en paralelo antes de que exista una aplicación contenedora (host) claramente definida. Ese fue mi caso: trabajaba en un módulo independiente que debía integrarse con otro módulo de mayor jerarquía, sin tener aún claridad sobre el host final.

En este escenario, el flujo era más o menos así:

Módulo principal (host, aún sin definir).
- Módulo Z (módulo padre).
  - Módulo X (módulo que solo vivirá dentro del módulo padre).

Esto trajo una serie de retos técnicos que fuimos resolviendo con buena comunicación y decisiones prácticas. En este artículo comparto algunas de esas prácticas que me sirvieron para lograr una integración funcional. Para el ejemplo, utilizaremos PrimeReact y Redux Toolkit como librerías de ejemplo.

1. Alinear versiones de librerías compartidas

Debemos identificar qué versiones de librerías está usando el módulo padre, para asegurarnos de que sean compatibles con el módulo que vamos a integrar.

"primereact": "9.6.1",
"primereact-icons": "9.6.1",
"react-redux": "9.6.1",
"@reduxjs/toolkit": "2.5.0",

Esto debe quedar reflejado también en el webpack.config.js dentro de la sección shared:

shared: {
  // ... otros shared: react, react-dom, react-router-dom, etc.
  "primereact": {
    singleton: true,
    strictVersion: true,
    requiredVersion: deps["primereact"],
  },
  "primereact-icons": {
    singleton: true,
    strictVersion: true,
    requiredVersion: deps["primereact-icons"],
  },
  "react-redux": {
    singleton: true,
    strictVersion: true,
    requiredVersion: deps["react-redux"],
  },
  "@reduxjs/toolkit": {
    singleton: true,
    strictVersion: true,
    requiredVersion: deps["@reduxjs/toolkit"],
  },
  // ... otros shared
}

2. Configura el nombre del módulo y lo que expone

Configura correctamente el webpack.config.js para exponer lo que realmente necesita el módulo padre(host). Esto incluye tu componente principal, slices, hooks, adaptadores, etc. Todo lo que necesite tu módulo para que funcione correctamente.

...
name: 'moduleAppX',
filename: 'remoteEntry.js',
exposes: {
  "./ModuleComponent": "./src/main.tsx",
  "./ModuleSlices": "./src/application/slices/index.ts",
  "./ModuleApi": "./src/infrastructure/http/apiClient.ts",
  "./ModuleHooks": "./src/application/hooks/expose.ts",
  "./ModuleAdapter": "./src/application/adapters/expose.ts",
},
...

3. Evita conflictos con los estilos TailwindCSS

Cuando no hay un diseño UI unificado, cada equipo crea estilos tailwind para su módulo a su criterio. Por eso, para evitar conflictos, configura Tailwind (v3.4) para que sus clases estén encapsuladas:

module.exports = {
  content: ['./src/**/*.{ts,tsx,html}'],
  important: '#module-app-x', // Usa un id único de tu módulo
  theme: {
    extend: {},
  },
  plugins: [],
};

Y dependiendo de como crees tu componente principal(main), puedes usar el id único de tu módulo para que los estilos de tailwind solo afecten al contenido de tu módulo.


export const ModuleX = () => {
  return (
    <div id="module-app-x">
      <h1>Hola Mundo</h1>
    </div>
  );
};

4. Importa el CSS necesario en el componente remoto

Cuando utilizas otras librerías, como react-loading-skeleton, requieren importar su archivo CSS para que los estilos se apliquen correctamente. Si no lo haces, es posible que los componentes no se rendericen como deberían.

import 'react-loading-skeleton/dist/skeleton.css';

// ...

En mi caso, los estilos de react-loading-skeleton no se aplicaban hasta que los importé explícitamente en el componente remoto.

5. Integra tus reducers o middleware en el módulo padre (Redux Toolkit)

Coordina con el equipo del host cómo se van a integrar tus slices o servicios RTK. Asegúrate de exponerlos y que el host los incluya en su configureStore.

// En el módulo padre
import { moduleReducer } from 'moduleAppX/ModuleSlices';
import { api as apiModule } from 'moduleAppX/ModuleApi';

// En el store del módulo padre
const mainStore = configureStore({
  reducer: {
    // ... otros reducers
    // ModuleAppX
    modulo: moduleReducer,
    [apiModule.reducerPath]: apiModule.reducer,
    // ... otros reducers
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(apiModule.middleware),
});

Esto asegura que tu módulo pueda consumir la información desde el store del módulo padre.

6. Evita duplicar estilos que ya están en el host

Algunas librerías como PrimeReact o Bootstrap incluyen CSS que probablemente ya estén importados por el módulo padre. Verifica antes de incluirlos nuevamente para evitar conflictos de estilos.

7. Asegura la compatibilidad con TypeScript

Si usas TypeScript, crea en el módulo padre un archivo remote.d.ts para declarar los módulos remotos que vas a importar:

declare module 'moduleAppX/ModuleComponent';
declare module 'moduleAppX/ModuleApi';
declare module 'moduleAppX/ModuleSlices';
declare module 'moduleAppX/ModuleHooks';
declare module 'moduleAppX/ModuleAdapter';

Y asegúrate de que el módulo padre declare el remote en su webpack.config.js para que el autocompletado y los tipos funcionen correctamente.

...
remotes: {
  moduleAppX: 'moduleAppX@https://your-app-domain.xyz/remoteEntry.js',
},
...

8. Realiza pruebas aisladas e integradas desde el inicio

Es útil separar la lógica de tu componente en dos archivos:

main.tsx: solo exporta el componente que se va a consumir de forma remota.

import 'react-loading-skeleton/dist/skeleton.css';

export { ModuleX } from './presentation/pages/ModuleX';

bootstrap.tsx: para probar el módulo de forma individual, con todo el contexto necesario.

import { createRoot } from 'react-dom/client';
import { ModuleX } from './presentation/pages/ModuleX';
import { store } from './application/store';
import { Provider } from 'react-redux';
import 'primereact/resources/themes/saga-blue/theme.css';
import 'primereact/resources/primereact.min.css';
import 'primeicons/primeicons.css';

const container = document.getElementById('root')!;
const root = createRoot(container);

root.render(
  <Provider store={store}>
    <ModuleX />
  </Provider>
);

De esta forma, aseguramos el correcto funcionamiento de nuestro módulo dentro del módulo padre.

Conclusión:

Integrarse sin un host definido requiere comunicación, orden y algo de paciencia. Estas prácticas me ayudaron a lograrlo de forma más fluida, y espero que también te sean útiles si estás en una situación parecida.

MicroFrontend: el escenario ideal para una integración ordenada

Miguel Quispe — Mon, 02 Jun 2025 17:50:14 +0000

En esta segunda parte de la serie, comparto lo que considero un escenario ideal para integrar microfrontends desde el inicio. A diferencia de la parte anterior, aquí asumimos que ya existe una aplicación contenedora (host), un equipo técnico alineado, y acuerdos previos que permiten una integración más ordenada.

1. Definir el host desde el inicio

Establecer desde el comienzo cuál será la aplicación contenedora ayuda a los equipos a exponer correctamente sus módulos y a planificar la integración desde la arquitectura.

2. Tener responsables claros por módulo

Conocer desde el inicio quiénes son los responsables técnicos de cada módulo (como líderes técnicos, developers, etc.) permite una comunicación más fluida y una mejor autogestión del proyecto.

3. Alinear diseño y componentes UI globales

El equipo de diseño debe definir desde el inicio los componentes visuales comunes. Idealmente, estos deben estar en una librería compartida para asegurar consistencia entre módulos.

4. Compartir un template base de configuración

Contar con un template base (con configuración mínima de Webpack/Vite, alias, pruebas, bootstrap local, etc.) ayuda a mantener coherencia entre módulos desde el arranque.

5. Establecer contratos de integración

Cada módulo debe definir claramente qué expone y cómo se debe consumir. Esto incluye:

Componente principal
Props esperadas y eventos
Nombres de exportación
Punto de entrada y documentación básica de uso

Una convención clara facilita la integración entre equipos.

6. Identificar librerías compartidas y versiones

Definir qué librerías se compartirán (como React, Redux, etc.) y acordar versiones compatibles entre equipos. También es importante decidir si se usará siempre la versión más reciente o se respetará un rango (por ejemplo, solo actualizaciones mayores o de parches).

7. Tener un entorno de staging común

Un ambiente donde se integren todos los módulos antes de producción permite validar flujos reales y detectar errores de integración de manera anticipada.

Conclusión:

En desarrollo de software, todos quisiéramos partir de un escenario ideal. Pero la realidad muchas veces es distinta. Por eso, más allá de la planificación, lo que marca la diferencia es nuestra capacidad de adaptarnos, colaborar y construir soluciones incluso en contextos imperfectos.

¿Y tú? ¿Qué otro punto agregarías a este escenario ideal?

Gracias por leer, que tengas un día maravilloso. 🌞

MicroFrontend: consideraciones al trabajar sin una aplicación contenedora

Miguel Quispe — Mon, 02 Jun 2025 17:48:23 +0000

En muchos proyectos reales, los equipos comienzan a desarrollar sus módulos antes de tener una aplicación contenedora (conocida también como host o shell). Esta situación es común, especialmente en entornos ágiles, donde se busca avanzar de manera paralela sin bloqueos.

En esta primera parte comparto algunas consideraciones técnicas y organizativas que pueden ayudarte cuando se trabaja con módulos independientes, sin tener aún una aplicación contenedora definida.

1. Define claramente si trabajas con módulos o submódulos

Antes de comenzar, identifica si tu módulo se integrará directamente en la aplicación principal o será parte de otro módulo (un submódulo). Esto cambia las decisiones técnicas: desde qué dependencias necesitarás hasta cómo manejar el contexto.

¿Por qué esto importa? Un submódulo depende más del módulo que lo contiene. Anticiparlo evita reestructuraciones más adelante.

2. Diseña cada módulo como si fuera remoto

Aunque el módulo se monte temporalmente en otro para avanzar, es buena práctica tratarlo como un microfrontend independiente desde el inicio. Esto simplifica su futura exposición e integración.

3. Usa convenciones claras desde el inicio

Define cómo se expondrán los elementos principales del módulo, como componentes, slices, adapters y hooks. Algunos ejemplos comunes son: ./ModuloComponent, ./ModuloSlices, ./ModuloHooks.

4. Gestiona cuidadosamente las dependencias compartidas

Asegura que cada módulo configure correctamente sus dependencias compartidas (por ejemplo, react, react-dom, @reduxjs/toolkit) usando Module Federation con la opción singleton.

Además, todos los módulos deben usar la misma versión de estas dependencias para evitar errores o comportamientos inesperados al integrarse.

5. Mantén aislado el estado y los estilos

Cada módulo debería tener su propio estado local, sobre todo si aún no existe un store global. Esto ayuda a que los equipos trabajen sin depender unos de otros.

En estilos, conviene usar soluciones como Tailwind con prefix o CSS Modules. Así evitas conflictos visuales cuando se cargan varios módulos en una misma vista.

6. Exporta solo lo necesario

Durante el desarrollo es normal usar un archivo bootstrap para probar tu módulo de forma aislada. Allí puedes importar todo lo que necesites.

Pero al momento de exportarlo (por ejemplo, en main.tsx), incluye solo lo esencial. No dupliques recursos que ya aporta la aplicación contenedora, como los estilos de alguna librería de componentes.

7. Documenta claramente lo que expones

Un documento breve, pero claro, con lo que el módulo expone (componente, slice, hook, etc.) facilita que otros equipos lo integren sin fricción.

8. Comunicación constante entre equipos y apoyo mutuo

Aunque los equipos trabajen en paralelo, es clave mantener la coordinación. Reuniones cortas y constantes ayudan a alinear criterios y prevenir bloqueos antes de que escalen.

¿Por qué es importante? Coordinar temprano es más barato que corregir tarde.

Conclusión

La integración puede llegar después de varios sprints, cuando ya se espera ver avances funcionales de los módulos integrados. Por eso, mantener una buena comunicación entre equipos es esencial para evitar contratiempos.

Glosario

Aplicación contenedora (host / shell): Aplicación principal que orquesta e integra los módulos desarrollados de forma independiente. Se encarga de manejar navegación, estilos globales y carga dinámica de microfrontends.

Microfrontend: Módulo de frontend que se puede desarrollar, desplegar e integrar de manera autónoma, como parte de una aplicación mayor.

Module Federation: Funcionalidad de Webpack que permite compartir módulos entre aplicaciones en tiempo de ejecución.

Bootstrap (en este contexto): Archivo que sirve para probar un módulo de forma aislada, sin depender de la aplicación principal.

Singleton: Opción que se usa en Module Federation para compartir una sola instancia de una dependencia entre múltiples módulos.

Prefix (en Tailwind): Configuración que permite evitar conflictos de estilos entre módulos usando un prefijo en las clases CSS.

Gracias por leer, que tengas un día maravilloso. 🌞

Crear un menú responsive con CSS y JavaScript

Miguel Quispe — Fri, 08 Mar 2024 14:53:55 +0000

En este tutorial veremos el proceso de como crear un menú responsive, utilizando CSS y algo de JavaScript.

Estructura HTML

Antes que todo, debemos definir el meta tag viewport dentro del tag head, que nos permite configurar como se debe interpretar el contenido de nuestra web en los dispositivos móviles.

<meta
  name="viewport"
  content="width=device-width, initial-scale=1, maximum-scale=1"
/>

Ahora agregamos el código html para nuestro menú.

<header>
  <div id="logo">
    <a href="#">MQ</a>
  </div>
  <nav id="menu">
    <button class="nav-mobile" id="nav-mobile">
      <span></span>
      <span></span>
      <span></span>
    </button>
    <ul class="nav-menu">
      <li><a href="#">Inicio</a></li>
      <li><a href="#">Tutoriales</a></li>
      <li><a href="#">WordPress</a></li>
      <li><a href="#">Recursos Web</a></li>
      <li><a href="#">Demos</a></li>
    </ul>
  </nav>
</header>

Como puedes observar en el código de arriba, he creado un sencillo menú en una lista <ul/> con 5 enlaces, dentro del tag nav, también tengo un tag <a/> con id "nav-mobile", que nos servirá como botón para desplegar el menú.

Estilos CSS

Ahora aplicamos los estilos para para alinear el logo y el menú, en esta ocasión usaré SCSS. Es recomendable empezar por la vista mobile(mobile first). En los comentarios explicaré, un poco, que es lo que hace cada estilo definido.

// Definimos un ancho fluido y una altura fija para nuestro menú
header {
  background: #22282e;
  height: 60px;
  position: relative;
  width: 100%;
}

// El logo sera flotado a la izquierda
#logo {
  float: left;
  padding: 6px 20px;
  width: auto;
  height: 60px;

  a {
    display: block;
    text-decoration: none;
    text-align: center;
    color: #fff;
    font-weight: bold;
    line-height: 44px;
    text-transform: uppercase;
  }
}

// Fijamos nuestro nav en 100% ancho
#menu {
  position: absolute;
  top: 60px;
  width: 100%;

  // Quitamos estilos por defecto de el tag UL
  ul {
    max-height: 0;
    overflow: hidden;
    margin: 0;
    padding: 0;
    list-style: none;
    font-size: 14px;
  }

  // Convertimos nuestra lista de enlaces en un menú horizontal
  li {
    display: block;
    background: #33363b;
    text-transform: uppercase;
    text-align: center;
    border-bottom: 1px solid #282b30;

    // Damos estilo a nuestros enlaces
    a {
      display: block;
      color: #fff;
      text-decoration: none;
      line-height: 60px;
      padding: 0 26px;

      &:active,
      &:focus   {
        color: #ffc700;
      }
    }
  }

  // Agregamos una animación al despliegue del menú
  .open-menu {
    box-shadow: 0 1px 2px rgba(0,0,0,.5);
    max-height: 400px;
    transition: max-height .4s ease;
  }
}

// Botón mostrar menú
#nav-mobile {
  background: transparent;
  border: 0;
  cursor: pointer;
  float: right;
  width: 60px;
  height: 60px;
  position: absolute;
  right: 0;
  top: -60px;
  opacity: 0.6;

  // Agregaremos esta clase a #nav-mobile, cuando el menu mobile haya sido desplegado
  &.nav-open {
    opacity: 1;
  }

  span {
    display: block;
    width: 60%;
    margin: 4px auto;
    height: 4px;
    background: #fff
  }
}

Como pueden ver he definido un max-height:0 para el elemento ul y ocultado su contenido con overflow:hidden, esto se hizo para dar una animación cuando se despliegue el menú en la clase .open-menu.

Responsive

Utilizando media queries, establecemos los estilos para cambiar la apariencia de nuestro menú en diferentes tamaños de pantalla.

En este caso, he establecido un breakpoint para que nuestro menú cambie cuando el ancho de la pantalla sea mayor, o similar, al de una Tablet. Lo cual nos permitirá aplicar los estilos en pantallas más grandes.

/* .... Código anterior */
@media only screen and (min-width: 768px) {
  // ocultamos botón #nav-mobile
  #nav-mobile{ display: none; }

  // Nuestro nav con id #menu lo flotaremos a la derecha
  #menu {
    width: auto;
    float: right;
    top: 0;
    position: relative;

    .open-menu {
      box-shadow: none;
    }

    // Hacemos reset de max-height
    ul {
      max-height: inherit;
    }

    // Alineamos los items de forma horizontal
    li {
      float: left;
      border: 0;
      background: transparent;

      a {
        display: block;
        color: #fff;
        padding: 0 26px;

        &:hover {
          color: #ffc700;
          background: #151a1e;
        }
      }
    }
  }
}

En esta parte hemos ocultado el elemento #nav-mobile con un display:none, para que no se muestre en las pantallas de escritorio.

Desplegar menú con JavaScript

Finalmente, asignamos una función al evento click en #nav-mobile, con el método .on() de jQuery, que nos servirá para agregar la clase “nav-active”, y a la vez agregar la clase “open-menu” al elemento ul dentro de nav, con el método toggleClass de jQuery, para ver el despliegue del menú con una simpática animación definida en el css.

// JavaScript Version
const buttonMenu = document.querySelector('#nav-mobile');
const navMenu = document.querySelector('.nav-menu');

buttonMenu.addEventListener('click', (e) => {
  e.currentTarget.classList.toggle('nav-open');
  navMenu.classList.toggle('open-menu');
});

// jQuery Version
$(function() {
    var btn_movil = $(‘#nav-mobile’),
    menu = $(‘#menu’).find(‘ul’);

    // Al dar click agregar/quitar clases que permiten el despliegue del menú
    btn_movil.on(‘click’, function (e) {
        e.preventDefault();
        var el = $(this);
        el.toggleClass(‘nav-active’);
        menu.toggleClass(‘open-menu’);
    });
});

Demo

Y así es como tenemos un menú responsive que se adaptara a cualquier tamaño de pantalla.

¡Gracias por leer! Espero que haya sido útil para ti. ¡Que tengas un día maravilloso! 🌞