Micro frontends: cuándo dividir tu app (y cuándo no hacerlo)

¿Tu app realmente necesita micro frontends?

Micro frontends están de moda, pero no son la solución universal que muchos creen. Antes de dividir tu aplicación en pedazos más pequeños, necesitás evaluar si los beneficios superan la complejidad que van a agregar.

La decisión no es técnica pura: es estratégica. Dependé de tu equipo, tu producto y tu contexto específico.

Cuándo SÍ usar micro frontends

Equipos grandes y autónomos

Si tenés más de 3-4 equipos trabajando en el mismo frontend, los micro frontends empiezan a tener sentido. Cada equipo puede:

• Deployar independientemente
• Elegir su stack tecnológico
• Moverse a su ritmo sin bloquear a otros

En Mercado Libre, por ejemplo, diferentes equipos manejan checkout, búsqueda y perfil de usuario como aplicaciones separadas.

Productos con módulos claramente definidos

Tu aplicación tiene que tener límites naturales. Un ERP con facturación, inventario y contabilidad como módulos separados es candidato ideal.

Pero si tu app es un dashboard simple con 4-5 pantallas relacionadas, estás forzando divisiones que no existen.

Legacy y migración gradual

Tenés una aplicación vieja que necesitás modernizar pero no podés reescribir de cero. Los micro frontends te permiten migrar sección por sección:

// Aplicación host
const routes = {
  '/dashboard': loadLegacyApp(), // jQuery viejo
  '/analytics': loadNewReactApp(), // React nuevo
  '/settings': loadVueApp() // Vue más nuevo
};

Múltiples marcas o productos

Si manejás varias marcas que comparten funcionalidad básica pero necesitan UX diferentes, los micro frontends te dan flexibilidad sin duplicar código de negocio.

Cuándo NO usar micro frontends

Equipos chicos (menos de 10 devs)

Con pocos desarrolladores, la coordinación es fácil. Los micro frontends van a generar más problemas que beneficios:

• Overhead de setup y mantenimiento
• Complejidad de testing
• Problemas de comunicación entre módulos

Aplicaciones simples

Un blog, una landing page, o una app con pocas funcionalidades no justifica la arquitectura compleja. Seguí con un monolito bien estructurado.

Falta de experiencia en el equipo

Si tu equipo está aprendiendo React o Vue, no agregues micro frontends encima. Primero dominá las herramientas básicas.

Presupuesto y tiempo limitados

Los micro frontends requieren inversión inicial significativa en:

• Setup de CI/CD para múltiples apps
• Configuración de module federation
• Testing end-to-end complejo
• Monitoreo distribuido

Si tenés deadline apretado, no es momento de experimentar.

Criterios de evaluación práctica

Checklist de decisión

Respondé estas preguntas honestamente:

• ¿Tenés más de 8 desarrolladores frontend?
• ¿Los deploys están bloqueados por conflictos entre equipos?
• ¿Tu app tiene módulos que cambian a ritmos muy diferentes?
• ¿Necesitás tecnologías diferentes para distintas partes?
• ¿Tu equipo tiene experiencia con arquitecturas distribuidas?
• ¿Podés invertir 2-3 meses en setup inicial?

Si respondiste "no" a más de 3 preguntas, quedáte con un monolito.

Señales de alarma

Estás considerando micro frontends por las razones equivocadas si:

• Querés "estar a la moda" con la arquitectura
• Pensás que va a resolver problemas de código mal estructurado
• Creés que es más fácil de mantener (no lo es)
• Tu única motivación es técnica, sin justificación de negocio

Alternativas antes de dividir

Monolito bien estructurado

Antes de fragmentar, intentá:

// Estructura por features, no por tipos de archivos
src/
  features/
    dashboard/
      components/
      hooks/
      services/
    analytics/
      components/
      hooks/
      services/
    shared/
      components/
      utils/

Module federation sin micro frontends

Podés compartir componentes entre aplicaciones sin arquitectura completa de micro frontends:

// webpack.config.js
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'design_system',
      exposes: {
        './Button': './src/components/Button',
        './Modal': './src/components/Modal'
      }
    })
  ]
};

Repositorios separados, deploy conjunto

Dividí el código en repos diferentes pero mantené un solo deploy. Reducís coordinación sin complejidad de runtime.

Si decidís seguir adelante

Empezá chico

No dividas todo de una. Probá con:

1. Un módulo no crítico
2. Que tenga límites claros
3. Que un equipo pueda manejar completamente

Inversión inicial necesaria

Tiempo estimado de setup: 1-3 meses dependiendo del equipo

Herramientas que vas a necesitar:

• Module federation (Webpack 5) o Single SPA
• CI/CD independiente por micro frontend
• Shared state management
• Error tracking distribuido
• Testing end-to-end robusto

Métricas para evaluar éxito

• Tiempo de deploy reducido
• Menor conflictos en merge requests
• Equipos deployando independientemente
• Bugs no se propagan entre módulos

Si no ves mejoras en estos puntos después de 6 meses, reconoce que tal vez no era la solución correcta.

Preguntas frecuentes

¿Los micro frontends son más lentos?

Pueden serlo si no los configurás bien. Cada micro frontend agrega JavaScript adicional y latencia de red. Necesitás optimización específica.

¿Cómo manejo el estado compartido?

Evitá estado compartido tanto como sea posible. Cuando no puedas, usá eventos del browser o un store específico para comunicación entre micro frontends.

¿Funciona con SEO?

Server-side rendering con micro frontends es complejo pero factible. Considerá si realmente necesitás SSR antes de agregar esta complejidad.