Esta es una lista con mis opiniones acerca de las prácticas más recomendadas al diseñar aplicaciones que siguen el patrón Micro-frontend. Se debe examinar cada “regla” y evaluar sus ventajas / desventajas en función de su caso de uso específico.

Cero Acoplamiento entre Micro-frontends

Para lograr los beneficios de esta arquitectura, se debe evitar el acoplamiento accidental lo más posible; esto desbloqueará la flexibilidad y escalabilidad que el patrón Micro-Frontend tiene para ofrecer, y preparar sus aplicaciones para el futuro al permitir actualizaciones incrementales o futuras reestructuraciones completas de partes de su aplicación.

Cada Micro-frontend debe poder renderizarse de forma independiente o dentro de un de un contenedor. La información requerida deben ser cargada por cada Micro-Frontend y evitar cascadas de datos.

Sí:

• ✅ Comparta librerías que se pueden intercambiar sin afectar a otros Micro-frontends.
• ✅ Cargue toda la información que necesita para renderizar.

Evite:

• ❌ Tenga un store centralizado / comparta datos cargados por diferentes Micro-Frontends.
• ❌ Comparta librerías que todavía estan en desarrollo.

Bases de código separadas

Cada Micro-Frontend debe tener su propia base de código y el control de versión elegido no debe tener ningún impacto en la forma en que se desarrolla o implementa el proyecto. Tener todos los proyectos bajo un solo monorepo o repositorios individuales está bien.

Sí:

• ✅ Usar Monorepos.
• ✅ Usar repositorios individuales.

Cada micro-frontend debe desplegarse de forma independiente

Cada Micro-Frontend debe tener su propio sistema CI/CD y ser capaz de desplegarse en producción cuando sea necesario sin depender de otros Micro-frontend. Un antipatrón común que debe evitarse es el “deployment queue of hell”, donde diferentes Micro-frontends están tan estrechamente acoplados que se necesitan desplegar en un orden específico para evitar romper la aplicación.

Sí:

• ✅ Tenga sistemas CI / CD separados.
• ✅ Despliege cuando se requiera.

Evite:

• ❌ Tener calendarios o agendas de despliegue programados.
• ❌ Tener despliegues secuenciales que dependen del resultado de un despliegue de otro Micro-Frontend.

Los Micro-Frontends se deben probar de forma independiente

Debido a que los Micro-Frontends se nececitan renderizar de forma independiente y también dentro de una aplicación contenedor, tiene sentido probarlos también de forma independiente utilizando unit tests y integration tests para ambos escenarios.

Sí:

• ✅ Tenga unit y integration tests para cada Micro-Frontend isolado.
• ✅ Corra integration tests para Micro-Frontends renderizando dentro de la aplicación contenedoras como parte del end-to-end testing.

Los micro-frontends deben tener versiones

Cuando se despliega un nuevo Micro-Fronted en producción, la versión anterior no debe eliminarse y la nueva versión debe etiquetarse con un número de versión utilizando semantic versioning o similar. Depende de las aplicaciones contenedoras el decidir qué versión específica de un Micro-Frontend en particular se debe cargar (Administrado) o si se debe cargar la última versión disponible (Evergreen).

Sí:

• ✅ Usar Semantic versioning.
• ✅ Usar versiones específicas o la etiqueta latest.

Evitar:

• ❌ Tener que desplegar toda la aplicacion
• ❌ Borrar versiones anteriores.

Comunicación Mínima

La comunicación entre Micro-Frontends debe ser mínima y simple, evitando tanto como sea posible el estado global y las soluciones específicas de otras librerías.

Si dos o más Micro-Frontends comparten una gran cantidad de mensajes para proporcionar su funcionalidad mínima, es posible que estén estrechamente acoplados y podrían compartir un propósito lo suficientemente similar como para considerar ser integrados en uno.

Si:

• ✅ Mantenga mensajes pequeños y simples.
• ✅ Evitar estado y librerías en lo posible.

Evite:

• ❌ Compartir estado (state).
• ❌ Tener comunicación innecesaria.

El CSS debe ser encapsulado

El CSS cargado desde un Micro-frontend no debería afectar a los demás.

Si:

• ✅ Encapsule el CSS.
• ✅ Use una libreria CSS-in-JS o una libreria que ayude con el namespace (CSS Modules).

Evite:

• ❌ Usar global CSS.

Recomendaciones finales

• ✅ Trate de crear equipos independientes.
• ✅ Trate de crear Micro-frontends alrededor de las necesidades del negocio.
• ✅ La reutilización es un “efecto secundario”, no el objetivo.
• ❌ No fuerce este estilo solo porque es “nuevo”.
• ❌ No necesita multiple JavaScript Frameworks.
• ❌ No necesitas un “micro-frontend framework”.
• ❌ Micro-Frontends no tienen que ser “micro”.