Infoxicator.com

Componentes vs Micro-Frontends. ¿Cuál es la diferencia?

Published

¿Son “solo componentes”?

Hace un tiempo, uno de mis colegas me envió un enlace a bit.dev diciendo: “¡Oye! ¡Mira esta increíble colección de micro-frontends y qué fácil es reutilizarlos en tu aplicación!”.

Eché un vistazo y pensé, ¡esto se ve increíble! pero … ¿son “micro-frontends” o simplemente “componentes“? 🤔.

Esta es una pregunta común y algunas personas argumentan que los micro-frontends son solo un buena libreria de “componentes”.

Entonces, ¿hay alguna diferencia entre “micro-frontends” y solo “componentes”? ¡Vamos a averiguar!

Un Problema Específico

Hace un tiempo, hubo un hilo en Twitter sobre micro-frontends y encontré la respuesta a continuación:

La arquitectura micro-frontend es un paradigma que intenta resolver un problema específico: ayudar a las grandes organizaciones a escalar aplicaciones desarrolladas por múltiples equipos en múltiples unidades de negocios o dominios. Para resolver este problema, las aplicaciones se pueden dividir en experiencias pequeñas, reutilizables, desarrolladas e implementadas de forma independiente.

Por lo tanto, el problema tiene más que ver con la forma en que las empresas organizan sus equipos y resuelven los problemas causados por la escala de la aplicación y los micro-frontends proporcionan la arquitectura y las herramientas para permitir la división vertical de características para que sea posible lograr esta separación.

Despliegues Independientes

Se puede lograr mucho con una libreria de componentes declarativos; nos permiten evitar el acoplamiento accidental, lograr un alto porcentaje de reutilización e incluso crear diferentes dependencias que pertenecen a diferentes equipos; sin embargo, a medida que las aplicaciones se vuelven más complejas, el modelo de componentes puede alcanzar su capacidad y comienza a ser más y más difícil administrar grandes bases de código y la coordinación entre diferentes equipos en diferentes partes de la organización se vuelve inmanejable. Una de las principales características de las micro-frontends es que se pueden implementar de forma independiente.

La entrega independiente podría ser un verdadero momento crucial para las grandes organizaciones, ya que permitiría a sus equipos entregar más rápido y libremente y colaborar y reutilizar de manera más efectiva.

Datos y lógica empresarial

Los componentes son pequeñas unidades que producen una representación visual para el usuario, mientras que los micro-frontends podrían describirse como una colección de componentes que brindan un valor específico al usuario y son propiedad de un equipo específico con un objetivo claro.

Los micro-frontends solicitan toda la información que necesitan de los servicios backend y los presentan al usuario de manera concisa. Es fácil para ellos seguir el principio de responsabilidad única y debido a que están directamente relacionados con la información, es más fácil para los equipos tener la responsabilidad por la funcionalidad de principio a fin debido a la familiaridad con la lógica empresarial.

Un Ejemplo de la Vida Real

Echemos un vistazo a un sistema de reserva de vuelos:


Aunque es una pequeña parte de la interfaz de usuario, contiene muchas funciones. Maneja la validación del formulario, las llamadas API a los sistemas de agregación y la visualización y filtrado de resultados, etc.

Cada pieza resaltada en la imagen podría ser un componente individual. La característica clave aquí es que todos estos componentes juntos brindan un valor específico al usuario y podrían encapsularse en un solo dominio.

Ahora imaginemos que hay un equipo dedicado a cargo de esta experiencia y que es su responsabilidad mantener y lanzar nuevas actualizaciones cuando sea necesario.

Si tuviéramos que seguir el enfoque monolítico, nuestro equipo necesitaría tener el contexto de toda la aplicación, su sistema de compilación y la estructura del proyecto, además, debe existir coordinación con otros equipos para lanzar nuevas actualizaciones que se ajusten a la cadencia de lanzamiento.

El primer intento para resolver problemas de coordinación sería envolver todo el sistema de reservas en un componente más grande y luego compartirlo como una dependencia para que pueda ser consumido por diferentes partes de la aplicación, sin embargo, esto requerirá que se despliegue la aplicación principal, tambien, para poder incluir las nuevas actualizaciones, todos los demás equipos deben ser informados que se ha publicado una nueva versión para entonces agregarla a la aplicación principal.

Los micro-frontends reducen la necesidad de coordinación al proporcionar a los equipos con una base de código separada y un sistema de compilación CI/CD específico para la parte de la aplicación de la que son responsables. Se requiere poca o ninguna comunicación, ya que las nuevas actualizaciones serán implementadas por el equipo propietario de la función y la integración con la aplicación principal se puede lograr mediante la composición del lado del cliente o del servidor en tiempo de ejecución y en algunas configuraciones evitando despliegues innecesarios o reinicios completos del servidor.

Conclusión

Las micro-frontends son más que simples “componentes”. Son una nueva forma de diseñar su aplicación para permitir a los equipos entregar funciones de forma independiente. Los equipos son responsables de las funciones de principio a fin y trabajan para lograr objetivos específicos.

Este nuevo paradigma tiene como objetivo ayudar a proporcionar las herramientas técnicas necesarias para agrupar componentes y ensamblarlos en la página bajo una experiencia cohesiva que produce un desarrollo más rápido y la entrega oportuna de nuevas funciones a los usuarios.


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?