Infoxicator.com

Reglas de los Micro-Frontends

Published

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.

:

  • ✅ 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).

:

  • ✅ 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”.

Recent Posts

Do you own a Car 🚗? Here is how to tackle tech debt.

Most developers struggle to explain to product teams why addressing tech debt or refactoring code is important and why it is valuable to the company.

Modular Monoliths: Have we come full circle?

The promise to bring back the “good old productivity win” of monolithic frameworks like Ruby on Rails but keeping the modularity.

The case against DRY, Micro-Frontends edition.

“Don’t Repeat Yourself” How does a modular architectural approach affect the DRY principle?