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

How I translated my Next.js Blog

English is my second language and before I was proficient, I always found it really difficult to find tech resources in my own language. That’s why I decided to translate my blog and make all my content available in Spanish. Internationalization with Next.js Next.js has made Internationalization (i18n) a breeze with one of the most[…]

Rules of Micro-Frontends

This is an opinionated list of best practices when designing applications that follow the Micro-frontend pattern

Dark Mode Is Not Enough! Here is an alternative…

These days most websites have an option to toggle Dark mode, but what if I wanted more?