Código redundante enviado por la tubería con Micro-frontends

Entiendo que Micro-frontends es que el problema clave que resuelven es ayudar a las empresas a tener equipos múltiples y diferentes, trabajar en componentes individuales / pequeñas aplicaciones que se utilizarán para componer una gran aplicación web.

Aquí el problema clave que se resuelve es la capacidad de varios equipos para trabajar de forma independiente y aún así poder construir un gran compuesto. El problema NO se trata de tener un paquete de lanzamiento optimizado para el usuario final . ¿Es correcto ese entendimiento?

¿Es cierto que si tenemos múltiples aplicaciones pequeñas que se utilizan para componer una aplicación web grande, podríamos tener múltiples aplicaciones pequeñas que envíen la misma biblioteca de Javascript ( como Lodash ) a los navegadores de los usuarios finales como parte de su paquetes de proveedores individuales que conducen a que se envíe una cantidad de código duplicado / redundante al usuario?

¿No es una preocupación de la que deberíamos preocuparnos al diseñar la aplicación front-end?

Tiene toda la razón de que hay una compensación involucrada aquí: está intercambiando algunos aspectos de la experiencia del usuario para obtener una mejor experiencia del desarrollador (que a su vez podría mejorar la experiencia del usuario de diferentes maneras). ¿Vale la pena? Depende.

Por ejemplo, creo que Spotify usa este enfoque para dividir su interfaz de usuario en componentes aislados ( fuente ). Cada widget vive en un iframe y, por lo tanto, puede tener su propio conjunto de bibliotecas, etc. Tienen la restricción organizativa única de que el trabajo lo realizan los escuadrones autónomos (un equipo multifuncional). Esto hace que sea más difícil ponerse de acuerdo sobre los estándares de toda la empresa y luego cambiar estos estándares. Entonces, para ellos, las microfronteras ayudan a preservar cierta flexibilidad. Pero sin este enfoque, tal vez su aplicación de escritorio sería menos problemática.

El almacenamiento en caché de HTTP no va a ayudar mucho: cada micro frontend podría usar diferentes versiones de framework. Además, el costo de la duplicación no es solo la transferencia de datos, sino los costos del lado del cliente de (re) compilar las bibliotecas y almacenar estructuras de datos duplicadas.

Personalmente, creo que tales microfronteras pueden ser una arquitectura válida, pero probablemente no sean aconsejables a menos que

• usted es una organización muy grande con equipos altamente autónomos que trabajan en la interfaz de usuario y necesitan realizar lanzamientos muy frecuentes (por ejemplo, diariamente) y
• su presupuesto de rendimiento de UX tiene espacio para esta duplicación, o su producto es tan bueno que UX no importa. Tenga en cuenta que el rendimiento debe probarse en dispositivos de gama baja, no en su máquina de desarrollo.

Si su organización no es enorme o si sus equipos son un poco más especializados, podría ser más fácil para todos los involucrados (administración, desarrolladores y, en última instancia, usuarios) tener un proceso común de construcción e implementación que evite la duplicación innecesaria. Por ejemplo, si solo tiene 4 equipos trabajando en la interfaz de usuario, probablemente puedan hablar entre ellos para acordar un conjunto común de bibliotecas y cómo integrar su trabajo en una arquitectura coherente.

Las micro-frontends parecen ser una de estas cosas que son realmente geniales, pero que no necesitas hasta que operas a escala.