De monolito frontend a microfrontends, paso a paso

Puedes pasar de un frontend grande a microfrontends sin congelar el desarrollo y sin un lanzamiento de una sola vez. El monolito sigue funcionando mientras las áreas salen una a la vez.

Antes de empezar

Confirma que los microfrontends son la respuesta correcta. Ayudan cuando varios equipos se bloquean entre sí en una misma base de código y un mismo proceso de publicación. Si un solo equipo es dueño de todo el frontend, sale más barato mejorar los límites entre módulos dentro del monolito. La decisión se explica en cuándo usar microfrontends y en reescribir, híbrido o microfrontends.

Si la respuesta es sí, el método es el patrón strangler. La estructura nueva crece alrededor de la aplicación vieja y la reemplaza una pieza a la vez, hasta que la aplicación vieja es tan pequeña que se puede retirar o dejar como una parte más.

Paso 1: Dibuja los límites dentro del monolito

Hazlo antes de cualquier trabajo de infraestructura. Lista las áreas de negocio, las rutas de cada una y el equipo responsable. Después revisa los imports entre áreas.

• Mueve el código de cada área a su propia carpeta o librería.
• Elimina los imports directos entre áreas. Reemplázalos por una API pública pequeña o por un evento.
• Separa lo que de verdad es compartido (sesión, layout, design system) de lo que se comparte por accidente.

Este paso tiene valor aunque te detengas aquí. También muestra qué áreas son fáciles de extraer y cuáles están enredadas.

Paso 2: Deja que el monolito sea el primer host

No necesitas un shell nuevo el primer día. El inicio más simple es agregar federación al monolito existente para que pueda cargar un remoto en ejecución. El monolito conserva el login, el layout y el router. Una ruta ahora apunta a código que se compila y se despliega en otro lugar.

Más adelante, cuando la mayoría de las áreas hayan salido, lo que quede del monolito será el shell. Algunos equipos prefieren construir primero un shell limpio y montar el monolito adentro. Es la opción habitual cuando el monolito corre en un framework antiguo. Mira una app legacy dentro de un host de microfrontends.

Paso 3: Construye la plataforma mínima

Antes de mover la primera área deben existir algunas piezas:

• Una forma de cargar remotos en ejecución y un manifiesto que diga dónde vive cada uno.
• La sesión, compartida del host al remoto.
• Reglas de rutas: el host es dueño del primer nivel y cada remoto es dueño de su prefijo.
• Un paquete de design system, aunque sea pequeño, para que el área extraída se vea igual.
• Un pipeline que compile y despliegue un remoto por separado, con rollback.

Paso 4: Extrae la primera área

La elección de la primera área importa más que la tecnología. Busca:

• Un límite de negocio claro y un único equipo dueño.
• Pocas dependencias con otras áreas.
• Uso real, para que el resultado signifique algo, sin que sea el flujo más crítico del producto.
• Un equipo que quiera hacerlo.

Mueve el código a su propio proyecto, expón sus rutas y apunta la ruta del host al remoto. Publícalo primero detrás de un feature flag o para un grupo pequeño de usuarios. Conserva el código viejo en el monolito hasta que el remoto esté estable en producción, y después bórralo.

Paso 5: Repite, área por área

Después de la primera área, el camino es conocido y cada extracción debería costar menos. Algunas reglas mantienen la entrega en marcha:

1. Sin congelamiento. El desarrollo de funcionalidades sigue en el monolito para las áreas que no se han movido. Un área se congela solo durante el período corto de su propia extracción.
2. Una extracción a la vez por equipo. Las extracciones en paralelo de equipos distintos están bien. Dos a la vez en el mismo equipo son demasiado.
3. Arregla la plataforma a medida que aprendes. Cada extracción encuentra vacíos en el host, el design system o el pipeline. Corrígelos en la plataforma y evita los parches locales.
4. Mide el avance por rutas. Compara las rutas que sirven los remotos con las que siguen en el monolito. Es un número que todos entienden.

Paso 6: Decide cuándo parar

La extracción completa es opcional. Detente cuando el costo que falta sea mayor que el beneficio que falta.

Buenas razones para dejar código en el monolito:

• El área casi no cambia.
• Ningún equipo es dueño, y crear un remoto no crearía un dueño.
• Es pequeña y está muy ligada al shell, como la configuración o el perfil del usuario.

En el estado final, el monolito viejo desapareció, quedó reducido al shell, o se mantiene como un remoto más que resulta ser más grande que los otros.

Lo que suele salir mal

• Dividir por capa técnica. Un remoto de componentes y otro de servicios crean acoplamiento sin independencia. Divide por área de negocio.
• Mezclar la migración con un rediseño. Primero mueve, después rediseña. Si ambos cambian juntos, no puedes comparar el comportamiento viejo con el nuevo.
• Plataforma sin dueño. El host, el pipeline y el design system necesitan un equipo. Mira equipos y ley de Conway.

Más en esta sección

• Una app AngularJS legacy dentro de un host de microfrontends
• Equipos, límites de propiedad y ley de Conway
• El costo real de los microfrontends
• Errores comunes en microfrontends y cómo evitarlos