NUCBA - Formación profesional digital

El momento exacto para considerar micro frontends

Los micro frontends no son una moda pasajera ni la solución mágica a todos los problemas de frontend. Son una arquitectura que resuelve problemas específicos de equipos específicos.

La pregunta no es "¿cómo implemento micro frontends?" sino "¿necesito micro frontends?"

Estás en el momento justo si tenés:

Equipos de 15+ desarrolladores trabajando en la misma aplicación
Despliegues bloqueados porque un equipo está esperando que otro termine su feature
Tecnologías mixtas que querés mantener (React + Vue, o migración gradual)
Dominios de negocio claramente separados (billing, user management, analytics)

Si tu equipo es de 3-8 personas, probablemente los micro frontends te van a generar más complejidad que beneficios.

Las tres arquitecturas que realmente funcionan

Module Federation con Webpack 5

Es la opción más madura para equipos que ya usan Webpack. Te permite compartir dependencias y cargar módulos remotos en tiempo de ejecución.

// webpack.config.js del host
const ModuleFederationPlugin = require('@module-federation/webpack');

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        mf1: 'mf1@http://localhost:3001/remoteEntry.js',
        mf2: 'mf2@http://localhost:3002/remoteEntry.js',
      },
    }),
  ],
};

Cuándo usarlo: Cuando tus equipos trabajan con React/Vue y querés compartir dependencias comunes como React DOM.

Single-SPA

Un framework agnóstico que maneja el routing y lifecycle de múltiples SPAs.

// Registrar micro frontends
import { registerApplication, start } from 'single-spa';

registerApplication({
  name: '@company/navbar',
  app: () => System.import('@company/navbar'),
  activeWhen: ['/'],
});

registerApplication({
  name: '@company/dashboard',
  app: () => System.import('@company/dashboard'),
  activeWhen: ['/dashboard'],
});

start();

Cuándo usarlo: Para migrar gradualmente de una tecnología a otra, o cuando tenés equipos trabajando con diferentes frameworks.

Server-Side Composition

El backend ensambla los diferentes micro frontends antes de mandar la respuesta.

Cuándo usarlo: Cuando el SEO es crítico y preferís evitar JavaScript en tiempo de ejecución.

Los errores que van a arruinar tu implementación

Error #1: Micro frontends por micro frontends

Vi equipos que dividieron su aplicación en 15 micro frontends porque "es la arquitectura moderna". Resultado: un infierno de debugging y despliegues.

La regla: Un micro frontend por equipo, no por feature.

Error #2: Shared state entre micro frontends

Si necesitás compartir estado complejo entre micro frontends, probablemente no necesitás micro frontends.

// ❌ Mal: Estado compartido complejo
const SharedStore = {
  user: {...},
  cart: {...},
  notifications: {...}
};

// ✅ Bien: Solo data esencial
const SharedContext = {
  userId: '123',
  theme: 'dark'
};

Error #3: No definir boundaries claros

Cada micro frontend debe ser completamente independiente. Si el micro frontend A no puede funcionar sin el micro frontend B, tenés un problema de diseño.

Estrategia de implementación paso a paso

Fase 1: Identificar boundaries

Antes de tocar código, mapeá tu aplicación por dominios de negocio:

Shell/Host: Navigation, routing, shared layout
User Management: Login, profile, settings
Core Business Logic: Tu feature principal
Secondary Features: Analytics, notifications, help

Fase 2: Implementar el shell

El shell es tu aplicación principal que va a cargar los otros micro frontends.

// shell/src/App.jsx
import React, { Suspense } from 'react';
const UserMicroFrontend = React.lazy(() => import('userMF/UserApp'));
const DashboardMF = React.lazy(() => import('dashboardMF/Dashboard'));

function App() {
  return (
    <Router>
      <Navigation />
      <Suspense fallback={<div>Loading...</div>}>
        <Routes>
          <Route path="/users/*" element={<UserMicroFrontend />} />
          <Route path="/dashboard/*" element={<DashboardMF />} />
        </Routes>
      </Suspense>
    </Router>
  );
}

Fase 3: Migrar de a uno

No migres todo junto. Empezá por el micro frontend menos crítico y más aislado.

Fase 4: Configurar CI/CD independiente

Cada micro frontend necesita su propio pipeline de deploy.

# .github/workflows/user-mf.yml
name: User Micro Frontend
on:
  push:
    paths: ['packages/user-mf/**']

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy User MF
        run: |
          cd packages/user-mf
          npm run build
          aws s3 sync dist/ s3://user-mf-bucket/

Testing y debugging: tu nuevo dolor de cabeza

Testing de integración

Necesitás testear que los micro frontends funcionen juntos:

// integration.test.js
import { render } from '@testing-library/react';
import { loadMicroFrontend } from './test-utils';

test('user micro frontend loads in shell', async () => {
  const UserMF = await loadMicroFrontend('http://localhost:3001/remoteEntry.js');
  render(<UserMF />);
  // assertions
});

Debugging distribuido

Implementá logging centralizado desde el día uno. Vas a necesitarlo.

// shared-utils/logger.js
export const logger = {
  error: (message, meta) => {
    console.error(`[${meta.microFrontend}] ${message}`, meta);
    // Send to centralized logging service
  }
};

El costo oculto que nadie te cuenta

Los micro frontends no son gratis:

Bundle size: Vas a duplicar dependencias
Complejidad operacional: Más deploys, más monitoring, más debugging
Performance: Runtime composition tiene overhead
Team coordination: Necesitás más comunicación, no menos

En una startup de 10 personas, estos costos pueden ser prohibitivos. En una empresa de 100+ desarrolladores, pueden ser la diferencia entre entregar features o estar siempre "refactoring".

Cuándo NO implementar micro frontends

Tu equipo tiene menos de 10 desarrolladores
Tu aplicación no tiene dominios de negocio claros
Estás buscando resolver problemas de performance (hay mejores opciones)
No tenés experiencia con CI/CD avanzado
Tu aplicación es principalmente CRUD sin lógica compleja

Los micro frontends resuelven problemas organizacionales, no técnicos. Si tu problema es que el bundle es muy grande, usá code splitting. Si es que el app es muy lenta, optimizá rendering. Si es que el código es difícil de mantener, refactorizá.

Pero si tenés equipos pisándose constantemente, deploys bloqueados por features de otros equipos, y dominios de negocio que podrían vivir independientes, entonces sí: los micro frontends pueden cambiar tu vida laboral para mejor.

Cuándo dividir tu frontend mejora la productividad del equipo