¿Qué son los micro frontends?
Los microservicios han arrasado con el desarrollo de back-end. Las micro interfaces toman prestado de este enfoque para organizar el desarrollo de aplicaciones complejas. Con la arquitectura de micro-frontend, una aplicación web está segmentada en distintas secciones, cada una manejada por equipos independientes.
Los micro frontends abordan el problema de los monolitos frontales no escalables, posiblemente mantenidos por docenas de equipos de desarrollo al mismo tiempo. En tales situaciones, uno puede encontrar que las mejoras adicionales, así como el mantenimiento del producto, se vuelven casi imposibles debido a la complejidad centralizada.
Además de eso, una tarea tan básica como cambiar una etiqueta en la aplicación puede llevar horas debido a un proceso de compilación lento, sin mencionar que algunas herramientas pueden comenzar a perder estabilidad cuando se someten a pruebas de estrés con potencialmente miles de archivos JavaScript.
La idea no es nada nuevo conceptualmente, ya que se basa en el enfoque de divide y vencerás. La definición misma de este enfoque asume que un equipo posee una parte particular de la aplicación de un extremo a otro, desde la capa de la base de datos, pasando por los servicios de back-end y el front-end.
Otro supuesto importante es que el equipo está facultado para elegir cualquier marco a su voluntad, según se adapten a sus habilidades y a los requisitos comerciales de la aplicación que poseen. Deben poder realizar su trabajo de forma independiente, sin coordinación, así como trabajar de forma aislada sin pisarse los dedos de los pies.
Este artículo cubrirá un enfoque que tomamos aquí en CCBill para nuestros robustos sistemas de administración. Hasta ahora nos ha ayudado mucho a contener la cantidad de JavaScript heredado que usamos en nuestros proyectos, así como a permitir actualizaciones incrementales de bases de código, compilaciones de integración continua (CI) más rápidas y estructuras de proyecto simplificadas.
Caso de uso de Micro Frontends: Aplicación de comercio
Este artículo analizará el concepto y el enfoque que tomamos en función de una aplicación comercial de ejemplo. En las siguientes secciones, cubriremos una serie de enfoques necesarios para lograr tal división, con un enfoque en ejemplos prácticos. En CCBill, tomamos el camino de la composición de front-end donde los submódulos son recuperados dinámicamente por el cliente utilizando división de código y carga lenta. La alternativa es un compositor de back-end implementado en la capa de servicios.
Figura 1: Ejemplo simulado de vista de panel de aplicación de negociación
La imagen de arriba muestra la vista de múltiples fragmentos de la aplicación web de comercio de ejemplo, compuesta por múltiples micro interfaces. Además, algunas acciones en cada una de esas micro interfaces pueden conducir a una vista separada que es manejada completamente por uno de los módulos, por ejemplo, detalles de una idea o noticia.
- Gráficos de equipo (HTML puro y JavaScript)
- Análisis técnico en equipo (Angular)
- Noticias del equipo (angular)
- Ejecución de operaciones en equipo (jQuery)
- Comunidad del equipo (Angular.js)
Manejo de dependencia
Dado que una de las suposiciones principales es que los equipos están autorizados a tener una pila de front-end de su elección, tenemos que mitigar el inconveniente más obvio: reducir la cantidad de scripts duplicados enviados al navegador.
Cuando miramos nuestro panel de ejemplo, posiblemente carguemos el Angular apilar dos veces, y esto claramente tendría un impacto negativo en el tiempo de carga y, por lo tanto, en la experiencia del usuario de nuestro producto. Analizaremos algunas técnicas que se podrían implementar para abordar este problema.
Desduplicación
Una opción para reducir la redundancia entre micro frontends es aprovechar un concepto denominado externos en webpack. Con los externos configurados, cuando se ensambla el paquete, en lugar de colocar el código de la biblioteca junto con él, nos referimos a una variable global de nuestra elección.
Aquí hay un ejemplo de un jQuery configuración externa:
…
/*
* Libraries provided outside of webpack:
* require('jquery') will result in referencing window.jQuery
*/
externals: {
jquery: 'jQuery'
},
…
Fragmento 1: una forma de definir un paquete externo en web
Esto resultará en paquete web usando la variable global al resolver jQuery importaciones
Para que esta configuración sea completamente funcional, tenemos que entregar jQuery a la aplicación de alguna manera, por ejemplo, a través de una etiqueta de secuencia de comandos HTML. Por lo tanto, la jQuery La biblioteca se cargará solo una vez, a pesar de que cada micro interfaz hace referencia a ella por sí sola. Otro beneficio es la coherencia de la versión de la biblioteca en las micro interfaces.
Cuando se trabaja con externos, es una buena idea incluir la biblioteca externalizada como una dependencia de desarrollo en su package.json. De esa manera, puede ejecutar el front-end separado del resto de la aplicación, así como realizar tareas comunes como la ejecución de pruebas unitarias.
Agrupación y división de código
Si su aplicación aún no está aprovechando HTTP2, podría ser una buena idea agrupar dependencias comunes de terceros para limitar la cantidad de solicitudes que obtienen recursos.
Tenga en cuenta que esta técnica, aunque limita la cantidad de solicitudes de red, tiene un efecto negativo en el almacenamiento en caché. Si agrupa a sus terceros en lugar de hacer referencia a ellos uno por uno desde un CDN de uso común, obliga a sus usuarios a descargar el paquete común al menos una vez por versión recién lanzada, en comparación con una alta probabilidad de que su navegador ya tuviera la biblioteca de terceros. almacenado en caché de la CDN. La situación empeora mucho sin la ruptura de la memoria caché basada en el contenido o el control de versiones manual del paquete, especialmente en combinación con lanzamientos frecuentes.
Juntos con paquete web externos, es fácil realizar bibliotecas de terceros des-duplicadas. En los casos en que la agrupación se implementa utilizando distribuciones UMD, se puede modificar el proceso de agrupación de producción (utilizando gulp, gruñido u otras herramientas).
Uno de los principales inconvenientes de externalizar las dependencias de terceros es la posible necesidad de sincronizar las versiones de dependencia entre las micro interfaces. Si bien es beneficioso para el producto final, esto puede plantear desafíos a los equipos de desarrollo, donde es necesario realizar algún tipo de actualizaciones sincronizadas. Sin embargo, las actualizaciones graduales son una opción, donde coexisten dos versiones a medida que los equipos tienen la oportunidad de actualizar su dependencia a su conveniencia. Ambas versiones de la biblioteca de terceros se pueden implementar y servir simultáneamente, utilizando un nombre de paquete o una ruta como discriminador de versiones.
…
<script src="/stitching-layer/angular.bundle.8.0.0.js">; </script>
…
<script src="/stitching-layer/angular.bundle.content-hash1.js"> </script>
…
Fragmento 2: ejemplo de convención de nomenclatura para el paquete común
Existen soluciones alternativas para lograr una carga singular de bibliotecas por ventana del navegador, como zona.js utilizado por Angular. Como alternativa al alojamiento de dichas dependencias en la capa de unión, con el soporte más reciente para importaciones dinámicas en las herramientas de compilación, podemos cargarlas dinámicamente de forma diferida según sea necesario y cuando aún no se hayan proporcionado.
Aislar conflictos de versiones
Hay al menos tres enfoques viables para abordar los choques de versiones de dependencia entre micro frontends.
Primero y posiblemente el enfoque más exigente es no permitir que ocurran tales situaciones. Es más fácil decirlo que hacerlo, ya que podría ser costoso actualizarlo. Al mismo tiempo, es posible que la versión anterior de un marco de ejemplo ya esté en desuso, lo que hace que su uso para cualquier desarrollo adicional de nuevos módulos sea inútil. En una situación en la que la migración del código base existente o permanecer en la versión anterior no es una opción, podemos tomar una de las siguientes rutas posibles para que coexistan.
Mencionemos brevemente el temido iframes como un medio para crear un ámbito de ejecución de JavaScript aislado. Hay muchos inconvenientes en la composición de su aplicación con este enfoque. Hemos estado allí, y alejarnos de una arquitectura basada en iframes simplificó mucho uno de nuestros portales de administración.
Los problemas relacionados con el cambio de tamaño y el manejo de modales, la navegación y el manejo de recarga de páginas, y la comunicación entre iframes se resolvieron alejándose de los iframes. Sin embargo, si es la única opción viable disponible, seguirá funcionando. Sin embargo, los iframes requieren bastante trabajo adicional.
La última opción por la que vamos a pasar es utilización de cierres. A los empaquetadores les gusta paquete web use cierres para construir paquetes. La biblioteca debe implementarse de tal manera que no contamine y utilice el objeto de ventana global, ofreciendo una forma más fácil de mantener de exponer su API.
Paquetes UMD por ejemplo, realizar la detección de características para determinar en qué entorno se ejecutan para utilizar la forma más adecuada de exponer sus API.
Comunicación entre aplicaciones
La mayoría de los marcos proporcionan una forma de comunicación entre las partes de la aplicación: difusión / emisión en AngularJS, entradas / salidas / servicios compartidos en Angular así como eventos personalizados en jQuery. Lo que necesitamos es una forma de comunicación independiente del marco entre las partes de la aplicación.
Una de esas opciones es Evento personalizado. Tiene un buen soporte de navegador con polyfill disponible para navegadores antiguos. Garantiza un acoplamiento flexible entre aplicaciones que siguen el patrón pub-sub e incluso apalancamiento delegación de eventos.
document.addEventListener("my:trader:buy", () => {console.log("Bought!");});
document.dispatchEvent(new CustomEvent("my:trader:buy"));
Fragmento 3: Pub-sub realizado con eventos personalizados
Alternativamente, si deseamos utilizar una forma de comunicación más visible utilizando servicios globales, esto también se puede lograr. En este caso, necesitaríamos utilizar un ámbito de ventana global para compartirlos, escritos como clases simples. Para limitar la contaminación del ámbito global, se recomienda declararlos en espacios de nombres.
Echemos un vistazo a cómo podría verse esta definición.
window.SPA = window.SPA || {};
window.SPA.services = window.SPA.services || {};
class TradingSessionService {
/**
* The constructor of TradingSessionService class
* @constructor
*/
constructor() {
}
…
}
SPA.services.tradingSessionService = new TradingSessionService();
(function() {
"use strict";
/**
* The constructor of AuthService class
* @constructor
*/
function AuthService() {
}
…
SPA.services.authService = new AuthService();
}());
Fragmento 4: dos formas de implementar servicios compartidos globales
El fragmento de código anterior presenta una forma de definir y exponer globalmente un servicio que utiliza una sintaxis de definición de clase tanto moderna como heredada. Para prevenir la contaminación de alcance global, los colocamos dentro del Servicios SPA. espacio de nombres
Compartir código
El código se puede compartir fácilmente a través de bibliotecas publicadas en un npm registro, lo que permite que los micro frontends los incorporen como cualquier otra dependencia.
Una consideración importante es que potencialmente estamos trabajando en un entorno donde coexisten múltiples marcos diferentes. Eso nos obliga a escribir las partes comunes de una manera agnóstica y, por lo tanto, reutilizable en todas ellas, lo que significa que las API de plataforma y JavaScript vanilla son nuestra apuesta más segura.
En nuestra aplicación comercial, pudimos identificar que estamos volviendo a implementar las reglas de validación de datos en cada una de nuestras micro interfaces. Es un buen candidato para la extracción en una biblioteca compartida, ya que encapsula una preocupación común.
La implementación del conjunto de validadores como funciones simples de JavaScript funcionaría perfectamente, ya que podremos aprovecharlo en todos los marcos utilizados.
Estado compartido
Si bien existen múltiples formas de lograr un estado compartido, lo ideal sería que se le diera fachada con un servicio disponible globalmente para facilitar el acceso y centralizar la lógica para acceder a dicho estado.
Si el estado tiende a mutar con el tiempo, por ejemplo a través de una websocket conexión, sería ideal utilizar algún tipo de sistema de notificación para notificar a las partes interesadas de tales eventos. Un ajuste natural sería un modelo pub-sub, que se puede lograr, por ejemplo, utilizando Eventos personalizados, o incluso un patrón de gestión estatal como redux, ya que es un marco agnóstico.
Capa compartida
¿Dónde deberían vivir todos los comunes? Servicios comunes, estado, configuraciones; claramente, no pueden pertenecer a ninguna de las micro interfaces individuales. En este punto, tenemos que introducir una entidad global: la capa de costura.
La capa de costura debe ser lo más delgada posible, y debe contener solo los elementos esenciales necesarios para que todas las demás partes de la aplicación funcionen correctamente. También desacopla todas las partes individuales, ya que puede actuar como mediador entre ellas.
Podemos suponer que cada micro interfaz solo debe conocer su propia existencia y lo que expone la capa de costura.
Figura 2: Comunicación y división entre componentes, incluida la capa de costura
Como ya se mencionó, se pueden poner partes comunes de la aplicación en la capa de unión, como el estado y los servicios (por ejemplo, Servicio de autenticación y Servicio de sesión comercial de nuestro código de muestra) así como hacerlo responsable del enrutamiento a nivel raíz, cargando los módulos de la aplicación. Se puede ver así como un lugar para componer todas las partes juntas y facilitar cualquier interacción entre las partes.
En nuestro caso, dado que optamos por la composición de front-end, la capa de costura necesitaría saber qué micro front-end cargar en una vista determinada. Esto se puede lograr utilizando un marco como spa único o una solución personalizada. Por ejemplo, para /noticias ruta de contexto se cargaría Noticias micro interfaz.
Navegación / Enrutamiento
Cada marco MV * proporciona un mecanismo de enrutamiento complementario, que utiliza la API del historial del navegador, las alternativas necesarias cuando es necesario e incluso maneja el enrutamiento del lado del servidor.
La pregunta es ¿cuál de las micro interfaces debería ser responsable de manejar el enrutamiento?
Dividir esta responsabilidad entre las micro frontends y la capa de costura es un enfoque posible. La capa de costura sería responsable del enrutamiento de más alto nivel (/noticias), determinando qué vista de nivel superior cargar. Además, el enrutamiento de grano fino sería manejado por la propia micro interfaz (/ noticias /: id) En este caso, el micro frontend de noticias cargará un elemento apuntado en la ruta secundaria /:identificación.
Estilo y UX
La consistencia puede convertirse en un problema cuando se trabaja en una configuración de micro interfaces. Uno puede caer fácilmente en una trampa en la que diferentes partes de la aplicación tienen un aspecto y una sensación diferentes, especialmente si se trabaja en equipos independientes. Esto puede resultar en una experiencia de usuario confusa y una sensación de desorden en la aplicación.
Para abordar este problema, se deben configurar y compartir pautas comunes de UI / UX con los equipos. Esta base de conocimientos debe propagarse junto con las herramientas y bibliotecas que ayudarán a lograr la coherencia, que es un conjunto de widgets común o un proveedor de estilo (es decir, bootstrap, materiales o una solución interna). Nuevamente, la parte agnóstica del marco juega un papel muy importante aquí, ya que debería ser fácil para cada equipo usar los widgets mencionados.
Cuando se trata de diseñar el Componentes web El enfoque es una particularidad importante gracias al sandboxing de CSS que usa DOM de sombra. Sin él, cualquier configuración de nivel empresarial que contenga varios equipos que trabajen en un solo producto corre el riesgo de caer en colisiones de reglas CSS. Para evitar estos problemas, configure convenciones de nomenclatura por equipo, para limitar o incluso eliminar la posibilidad de que se produzca un conflicto o una regla que se filtre desde una micro interfaz. Esto se puede lograr fácilmente utilizando cualquiera de los preprocesadores CSS disponibles (es decir, Less o Sass).
En nuestro caso, el equipo que trabaja en el gráfico utilizó el gráfico prefijo y el equipo que trabaja en la noticia, el noticias prefijo.
.chart {
&--candle {
...
}
&--updating {
...
}
}Fragmento 5: Prefijo de selectores de CSS realizado en Sass por el equipo de gráficos
Trabajando en aislamiento
Uno de los principales beneficios de las micro interfaces es la propiedad del código y el hecho de que un equipo determinado puede trabajar y lanzar una parte de la aplicación de forma aislada sin afectar el trabajo de otros equipos.
El equipo debería poder iniciar la micro interfaz en la que están trabajando, sin depender de otras partes de la aplicación. Probarlo junto con la capa de costura u otras micro frontales también es una preocupación importante. Esto permitirá la identificación temprana de cualquier problema de integración.
Nota: La calidad del trabajo diario también mejora mucho cuando puede abrir la aplicación de forma rápida y sencilla.
Existe una variedad de herramientas para elegir para ofrecer la funcionalidad mencionada. Nos centraremos en dos opciones:
- webpack-dev-servidor
- Browsersync.
En última instancia, el servidor HTTP más ligero con capacidades de proxy hará el trabajo.
Ejecutando como un servicio independiente
Nuestro objetivo es poder iniciar cualquier micro frontend independientemente del resto de la aplicación.
Dependiendo de las características de la interfaz que esté creando, es posible que deba establecer una comunicación auxiliar o proxy con la interfaz y proporcionar los datos contextuales y los recursos necesarios. Por ejemplo, un contexto de usuario conectado o una biblioteca de terceros que generalmente es proporcionada por la capa de unión).
Asumiendo paquete web es el paquete de su elección, usando webpack-dev-servidor servir su aplicación web es sencillo. Proporciona automáticamente compilaciones incrementales a medida que se realizan cambios en cualquiera de los archivos que se están viendo. De hecho, esto también es lo que CLI angular aprovecha debajo del capó para lograr lo mismo.
Además, utilice un index.html archivo para servir cualquier contexto proporcionado bibliotecas y / o apéndices de datos. Mientras escribe la configuración, es útil dividirla en varios archivos, que contienen partes comunes y desarrollador, productor y test Configuraciones
const webpackMerge = require("webpack-merge");
const commonConfig = require("./webpack.common.js");
module.exports = webpackMerge(commonConfig, {
devServer: {
index: "./index.html"
// your devserver config goes here
}
});
Fragmento 6: configuración de webpack-dev-server sobre la configuración común
Como se mencionó anteriormente, estamos incluyendo la parte común del paquete web configuración y fusionarlo con una configuración personalizada escrita para ejecutar el servidor de desarrollo. Estamos especificando el index.html ubicación del archivo, que se utilizará como punto de entrada para nuestro micro frontend. Hay algunas adiciones en él en comparación con la forma en que está expuesta para el consumo por la capa de costura. Los repasaremos a continuación.
<!doctype html>
<html lang="en">
<head>
<link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.4.1/jquery.min.js"></script>
</head>
<body>
<script>
var tradingSesion = {
// some data stubbed here
};
</script>
<app-news></app-news>
</body>
</html>
Fragmento 7: página de índice HTML que incluye recursos y datos que normalmente proporciona la capa de unión
Hay dos adiciones en este index.html archivo, es decir, estamos proporcionando datos contextuales dentro del guión etiqueta, así como dependencias, normalmente proporcionadas por la capa de costura. En nuestra aplicación de comercio de ejemplo, optamos por el diseño de materiales por lo que tenemos que proporcionar el CSS necesario, así como el jQuery biblioteca.
Integración con el resto de la aplicación
Sería muy conveniente si pudiéramos ver cómo los cambios aplicados a un micro frontend juegan junto con el resto de la aplicación.
Nuestra solución propuesta utilizará Browsersync. Tiene muchas capacidades, una de las más notables es la capacidad de reproducir acciones realizadas en un navegador en otros navegadores conectados. Nuestro caso de uso hoy en día es su capacidad para servir como proxy, con una configuración muy simple para proxy cualquier página, sirviendo partes de ella directamente desde un directorio local.
var bs = require("browser-sync").create();
bs.init({
proxy: "https://qa.my-trading.com",
serveStatic: [{
route: "/community",
dir: "./projects/community"
}, {
route: "/news",
dir: "./projects/news"
}]
});
Fragmento 8: aplicación de comercio de proxy de configuración de Browsersync implementada en un entorno de ensayo
Ahora estamos procesando todas las solicitudes de puesta en escena.my-trading.com, pero sirviendo los activos estáticos para /vibrante e inclusiva y /noticias contextos de / proyectos / comunidad y / proyectos / noticias directorios locales.
Submódulos Monorepos, Lerna y Git
Organizar la estructura de su proyecto es una preocupación tan importante como cómo se divide el código base. Monorepositorios resultan útiles cuando se trabaja en una configuración de este tipo.
En nuestra configuración propuesta, la capa de costura viviría en la raíz del monorrepositorio. Eso le da una buena visibilidad de sus componentes, además de actuar como un punto central para manejar cualquier tarea entre frentes, como por ejemplo, la definición de la Browsersync proxy para pruebas de integración.
Imagen 3: Estructura del monorrepositorio de la propuesta
Como se muestra arriba, definimos un proyecta directorio que contiene las micro interfaces que componen la aplicación. Aquí es donde submódulos de git Entra. Utilizándolos, podemos alojar el repositorio de cada micro frontend por separado, mientras brindamos la opción de tenerlos todos en una configuración agregada. Comprueba el historial, las ramas y las etiquetas, los trabajos de creación de CI, todos todavía están separados y son locales para cada micro interfaz.
Lerna es una opción bastante obvia aquí cuando se trata de manejo de monoreposidades. Nos permitirá ejecutar cualquier npm script en cada micro interfaz si es necesario. Por ejemplo, si quisiéramos construir la aplicación completa o realizar una prueba unitaria en múltiples micro interfaces después de un cambio realizado en una biblioteca compartida.
Establecer estándares comunes entre los proyectos, como una convención de nomenclatura para los scripts, es lo que hace posible esta configuración. Teniendo estándares comunes también permite que los recursos cambien entre proyectos más fácilmente. Por ejemplo, construir: ci En este caso, el comando sirve exactamente para el mismo propósito en cada micro interfaz y no es necesario buscar su funcionalidad.
lerna run build:ci --loglevel info --scope '{news,chart}'
Fragmento 9: Ejecución del comando build: ci en dos submódulos a través de lerna
El resultado del comando anterior será lerna ejecución test comando en noticias y gráfico, dando salida a los registros de cada uno de los submódulos.
Impacto HTTP2
La agrupación tradicional se vuelve problemática cuando se trabaja según la configuración propuesta. Agrupar para reutilizar y evitar duplicaciones se vuelve menos sencillo.
Algunas de las técnicas mencionadas pueden ayudar: bibliotecas comunes alojadas en la capa de unión, agrupadas por separado. Este enfoque a menudo se conoce como división de código y es un término medio entre agrupar su aplicación en un solo archivo y cargar cada archivo individual por separado. La agrupación hace que el almacenamiento en caché sea menos eficiente, ya que un cambio en uno de los archivos del paquete obliga al usuario a descargar todo el paquete de nuevo.
Por suerte gracias a HTTP2 este problema desaparece por completo ya que la agrupación es mucho menos importante. El navegador puede manejar de manera efectiva una gran cantidad de solicitudes concurrentes, así como utilizar otra técnica llamada servidor push para limitar la cantidad de viajes de ida y vuelta desde y hacia el servidor. Si está disponible, HTTP2 simplifica el trabajo en una configuración de micro frontend y el costo de simplemente incluir cada dependencia en la micro interfaz es insignificante gracias al almacenamiento en caché del navegador.
Comparación con la composición de back-end
Otro enfoque común para las micro interfaces es lo que se denomina composición basada en back-end, o fragmentos de servir.
En esta sección, destacaremos los pros y los contras de la composición basada en el front-end sobre la composición basada en el back-end.
Desventajas
- Capa de costura más gruesa, que podría verse como una micro interfaz propia.
- Más código y lógica enviados al cliente.
- SEO deficiente, ya que las partes de la página se solicitan de forma dinámica, los rastreadores tienen una capacidad limitada para indexar dichas páginas. Últimamente Google recomendó representación dinámica enfoque para mitigar este problema temporalmente.
- Más viajes de ida y vuelta y sobrecarga HTTP al buscar compuestos para vistas complejas.
Para Agencias y Operadores
- Pintura / carga inicial más rápida, mejor UX.
- Representación progresiva de las páginas, no es necesario esperar la respuesta más lenta hasta que se envíe HTML al navegador.
- Desacoplamiento del back-end, fácil de ejecutar como independiente usando un servidor HTTP.
- Opción para enviar fácilmente solicitudes de API para parte de la aplicación.
- Trabajos de CI separados, compilaciones más rápidas, mantenimiento más sencillo, bases de código independientes más pequeñas.
- No es necesario abrir la pila de back-end, el front-end se puede trabajar de forma independiente.
- Soluciones de código abierto listas para manejar composiciones, como spa único.
Está claro que hay muchos beneficios en la composición del front-end, pero también importantes inconvenientes (como pobre SEO), que puede no ser aceptable para todos los casos de uso.
Conclusión
Las micro interfaces ofrecen una alternativa atractiva al enfoque monolítico de crear interfaces de usuario. Permiten una mayor flexibilidad no solo en la utilización de marcos en el navegador, sino que también crean configuraciones de tiempo y estructuras de depósito.
Es importante recordar que este enfoque no siempre es de gran beneficio, especialmente para aplicaciones de tamaño pequeño a mediano. Sin embargo, cuanto más se acerca uno a las interfaces de tamaño de grado empresarial, más crucial se vuelve dividirlas en partes más pequeñas. Estos módulos pueden luego evolucionar de forma independiente y tener una propiedad bien definida, con un equipo dedicado que los mantiene.
Este patrón también, como es el caso de los microservicios, plantea algunos desafíos y complicaciones. Muchos aspectos, como la configuración inicial, la comunicación entre aplicaciones, la redundancia y la reutilización son más difíciles de manejar. Por lo tanto, el costo de la complejidad adicional debe incluirse al determinar el retorno de la inversión en función de su caso de uso particular.
Ir por la composición del front-end claramente no es el camino a seguir si el SEO es una gran preocupación para usted. Es más adecuado para sistemas robustos de tipo administrador. Sin embargo, también ofrece muchas ventajas, como un mejor desacoplamiento, menores costos de mantenimiento, separación de trabajos de CI y la capacidad de cargar el front-end en aislamiento de otras capas y sistemas.
En última instancia, lo que hemos ofrecido aquí hoy es otra herramienta válida para su caja de herramientas de desarrollo front-end. Uno que tenga mérito y sea efectivo en las circunstancias correctas.