Cómo construimos Micro Frontends

Cómo construimos Micro Frontends

En Bit, se crean herramientas para más de 100.000 desarrolladores que trabajan con componentes. Estas herramientas ayudan a los desarrolladores a construir, reutilizar y colaborar en componentes independientes para acelerar el desarrollo y mejorar la calidad de las aplicaciones.


Una gran ventaja de esto es la posibilidad de disfrutar de los beneficios de los Micro Front-Ends.


Al dividir el monolito de frontales en bases de código más pequeñas, los equipos de frontales pueden disfrutar de ventajas similares a las de los microservicios: bases de código mantenibles, equipos autónomos, lanzamientos independientes y actualizaciones incrementales.


Los micro frontales suelen considerarse como una composición de frontales independientes que se produce en tiempo de ejecución, ya sea en el servidor o en el lado del cliente.


Aunque las integraciones en tiempo de ejecución tienen sus ventajas (cargas útiles más pequeñas, por ejemplo), no son, ni mucho menos, la única forma de conseguir "una composición de aplicaciones frontales que se puedan entregar de forma independiente" (citando a Cam Jackson).


Esta nueva forma de construir y colaborar en aplicaciones frontales es, en nuestra opinión, el elemento central de los micro frontales.


Con el modelo de componentes y las herramientas adecuadas, cualquier equipo puede adoptar un enfoque modular para construir aplicaciones web y disfrutar de estas ventajas.


Para nosotros, componer aplicaciones frontales en tiempo de compilación aporta lo mejor de ambos mundos: la seguridad y robustez de los "monolitos tradicionales" y la simplicidad y escalabilidad de los micro frontales. Para ello, utilizamos Bit, una biblioteca de código abierto que ayuda a que cada componente sea completamente independiente, y nuestra plataforma en la nube que permite a los equipos colaborar e integrarse de forma eficiente.


En este artículo, mostraré cómo nosotros, en Bit, estamos construyendo micro-frontales. Explicaré cómo nos ha ayudado a alcanzar objetivos como bases de código desacopladas, equipos totalmente autónomos, actualizaciones incrementales independientes y una reutilización de código modular cercana al 100%. Espero que encuentres útil este conocimiento compartido.


Primero, un ejemplo en vivo

Si te diriges a la página de inicio de Bit.dev, notarás que ocurre algo extraño cada vez que pasas el ratón por encima de un componente.


Una vez que el ratón entra en un componente, se enciende un resaltador que indica el nombre del componente, la versión independiente y el ámbito en el que está publicado y expuesto. A medida que te desplaces, te darás cuenta de que toda la página está formada por componentes construidos, versionados y compartidos de forma independiente por diferentes equipos, en diferentes bases de código, utilizando diferentes procesos de construcción, y que están todos integrados en un producto con sensación de cohesión.


Lo que ves ahí es una demostración real de cómo nuestro equipo está utilizando tecnologías modernas basadas en componentes como React y Bit para construir micro front-ends.


En esta página, verás dos conjuntos de componentes, desarrollados por dos equipos. Uno es el conjunto de componentes "base-ui", propiedad de nuestro equipo de infraestructura front-end. El segundo conjunto es el "evangelist", propiedad de nuestro equipo de marketing.


Los componentes de ambos conjuntos se integran entre sí para componer rápidamente la página de inicio que se ve, así como otras páginas como la de empresa o la de soporte, e incluso para componer más aplicaciones.


Si hace clic en los ámbitos de los componentes, podrá ver con sus propios ojos la arquitectura de nuestro código base y nuestra estructura organizativa.


Un ámbito de componentes se llama "base-ui". Se trata del sistema de diseño de componentes más básico de Bit.dev, que contiene elementos básicos como el "párrafo", por ejemplo. Es propiedad del equipo de infraestructura del frontend y se desarrolla en su propia base de código desacoplada. Todos estos componentes se publican y comparten en Bit.dev. Allí, pueden ser fácilmente descubiertos e integrados en nuevos proyectos por cualquier otro equipo que los necesite. Y, el equipo que construye base-ui puede seguir enviando actualizaciones de forma incremental a componentes específicos.


El segundo ámbito se llama "evangelist". Se trata de nuestro sistema concreto de componentes orientados al marketing, utilizado para construir las páginas de marketing en nuestras aplicaciones. Es propiedad autónoma del equipo de marketing y se desarrolla en un código base desacoplado. Todos estos componentes se publican y comparten en Bit.dev, y son mantenidos por el equipo de marketing.


En este ejemplo, el equipo de marketing se desacopló del equipo que construye la plataforma web de Bit.dev. Este equipo trabaja en una base de código diferente, libera los cambios a través de su propia cadena de construcción desacoplada y puede entregar constantemente actualizaciones incrementales.


Cada equipo construye sus componentes, con la flexibilidad de dividir la propiedad vertical por características, etc., en su propia base de código más pequeña y desacoplada. Utilizan Bit para versionar, construir, probar, empaquetar y publicar independientemente cada uno de sus componentes. Utilizan la plataforma bit.dev para alojar y exponer los componentes a otros equipos, para que puedan integrarse y colaborar.


Cerca del 100% de los componentes escritos en nuestra base de código son compartidos y reutilizados, incluyendo no sólo los componentes del front-end, sino también muchos otros aspectos de nuestro sistema, como las características de "Búsqueda", las características de "Playground", e incluso ciertas características fullstack que incluyen funcionalidades tanto del front-end como del back-end.


Los indicadores clave de rendimiento y las evaluaciones comparativas que realizamos para nosotros mismos y para otros equipos muestran una serie de cosas positivas que ocurren cuando se adopta este diseño basado en componentes. Por ejemplo, el número de lanzamientos puede aumentar hasta 30 veces (¡!), el tiempo dedicado a las integraciones se reduce en más de un 50%, la composición de nuevas características se convierte en cuestión de horas o días, e incluso la incorporación de nuevos desarrolladores puede convertirse en una simple cuestión de horas en lugar de semanas. Puedes escuchar más sobre este cambio y lo que puede hacer por una start-up de rápido crecimiento de primera mano en este gran episodio del podcast JAMStack de HeavyBit.


Entonces, ¿Qué son realmente los micro frontales?

En los últimos años, los microservicios han permitido escalar las arquitecturas de backend a través de bases de código poco acopladas, cada una de las cuales es responsable de su propia lógica de negocio y expone una API, cada una de las cuales se puede desplegar de forma independiente, y cada una de ellas es propiedad de un equipo diferente y se mantiene.


Este paradigma proporciona grandes ventajas para ayudar a acelerar, escalar y hacer más eficiente el proceso de desarrollo.


La idea de los micro frontales es aportar las mismas ventajas al flujo de trabajo de desarrollo moderno. Significa dividir los proyectos monolíticos en piezas más pequeñas y manejables, que se desarrollan de forma independiente y son propiedad de los respectivos equipos, con el poder de construir y enviar simultáneamente.


Este concepto puede proporcionar grandes ventajas, como bases de código sencillas y desacopladas, equipos autónomos, lanzamientos independientes y actualizaciones incrementales. El proceso de desarrollo se acelera enormemente, se escala y se hace más eficiente.


¿Por qué es esto posible ahora y no antes?

Hasta hace poco, la mayoría de las aplicaciones web seguían construyéndose como proyectos monolíticos únicos. El fundador de GatsbyJS, Kyle Mathews, lo expresó muy bien diciendo que "los sitios web de hoy en día se siguen haciendo de la misma manera que hace 20 años, con un enfoque monolítico engorroso para construir sitios, almacenar datos y entregar contenido. Es hora de una nueva forma de construir la web".


Sin embargo, hoy en día, los componentes son el estándar primitivo de la web moderna. Sólo ahora estas piezas modulares y reutilizables están alcanzando su verdadera capacidad como bloques de construcción de nuestras aplicaciones web, permitiendo la descomposición modular de los monolitos tradicionales. Ahora, para aprovechar esta oportunidad, se necesita una infraestructura compartida que facilite el diseño modular basado en componentes para los equipos que construyen juntos las aplicaciones web.


Aquí es donde entran en juego nuevas herramientas como Bit, para proporcionar el conjunto de herramientas necesario para adoptar y disfrutar del desarrollo basado en componentes a nivel arquitectónico y organizativo, y cumplir con estos beneficios potenciales.


Bit permite a los desarrolladores desacoplar el desarrollo, la reutilización y la liberación de componentes independientes para que puedan ser desarrollados, reutilizados e integrados de forma eficiente para componer diferentes aplicaciones. Esto hace que Bit sea una poderosa herramienta para casos de uso como sistemas de diseño y componentes compartidos, pero también para la construcción de micro front-ends.


En Bit hemos trabajado con micro front-ends desde el primer día. Así es como hemos diseñado y probado nuestras propias herramientas, para que puedan ayudar a otros equipos a construir mejor con componentes. Hoy, nuestras herramientas ayudan a más de 100.000 desarrolladores a disfrutar de beneficios similares.


En este artículo, se mostrara como se está construyendo micro front-ends con componentes, como dividir el desarrollo web en bases de código desacopladas y mantenibles, facilitar el reemplazo o la integración de nuevas características y tecnologías, liberar a los equipos para que construyan y lancen los cambios de forma independiente a la producción, lograr una reutilización de componentes de hasta el 100%, y construir tanto una arquitectura escalable como una estructura organizativa que crezca sin problemas a medida que lo hacemos.


Nuestra infraestructura de componentes compartidos

Naturalmente, diferentes equipos utilizan diferentes pilas y herramientas para construir sus tecnologías.


Para el desarrollo de nuestra plataforma web y sitios web elegimos React. Con el lanzamiento de características como Hooks y Context-API, React se convirtió en una gran opción para nosotros para desarrollar aplicaciones modernas a partir de piezas más pequeñas, independientes y reutilizables.


Para una infraestructura de fragmentos que admita microfronteras basadas en componentes, utilizamos las herramientas de código abierto y la plataforma en la nube de Bit.


Además de alimentar nuestro producto a diario, Bit nos proporciona unas cuantas características necesarias para adoptar nuestra arquitectura de micro front-ends:


1. Nuestras herramientas OSS nos permiten desarrollar muchos componentes modulares en cualquier base de código, con un espacio de trabajo modular que nos ayuda a construir con componentes independientes. Los componentes pueden desarrollarse, renderizarse, construirse, probarse, versionarse, publicarse e incluso pasar por CI de forma independiente sin estar acoplados a ningún proyecto específico.


Además, Bit proporciona dos características más críticas: En primer lugar, proporciona un control universal sobre el gráfico de dependencias de todos los componentes. Resuelve automáticamente las dependencias de cada componente, y le permite saber exactamente lo que debe cambiar cada vez que hay un cambio en cualquier dependencia. En segundo lugar, proporciona entornos de desarrollo reutilizables y personalizables de 0-configuración para que los componentes puedan pasar por su propia tubería de construcción en la separación de cualquier proyecto más grande, y estos cambios se pueden construir a través de todo el gráfico de dependencia de los componentes.


Esto suena como mucho, y lo es, pero Bit realmente hace que sea bastante simple construir componentes independientes que pueden ser desarrollados y liberados por sí mismos.


2. Nuestra plataforma en la nube proporciona a los equipos (incluidos nosotros mismos) un centro de colaboración en el que todos pueden publicar componentes, documentarlos fácilmente (Bit automatiza este proceso), descubrirlos e instalarlos. Esto permite a nuestros equipos compartir y reutilizar cerca del 100% de los componentes que construimos.


Para asegurarse de que cada frontend tenga su propio proceso de construcción independiente y rápido, Bit también proporciona un proceso único de CI/CD que está 100% orientado a los componentes, lo que significa que los diferentes equipos pueden integrar de forma segura los cambios sin tener que esperar, luchar por el master o romper nada. Los desarrolladores pueden propagar de forma continua y segura los cambios en los componentes en todas las aplicaciones afectadas.


En lugar de construir cada proyecto monolítico en un solo proceso de construcción por el que todos los equipos tienen que pasar, el CI basado en componentes divide el proceso de construcción para que sólo se ejecute en los componentes que realmente cambiaron, y propaga los cambios infinitamente hacia arriba en su gráfico de dependencias, para construir cada componente impactado, en cada página, en cada aplicación.


Esto nos permite liberar la tubería de liberación de los diferentes equipos, de modo que cada equipo puede liberar de forma independiente y continua los cambios y actualizaciones a la producción. También significa que las compilaciones son 50 veces más rápidas, ya que no se construye todo. Además, podemos localizar los problemas y los errores hasta los componentes específicos.


Los cambios exitosos pueden traducirse automáticamente en pull-requests que se envían automáticamente a todos los proyectos relevantes, para que sus mantenedores puedan adoptar los cambios con seguridad y asegurarse de que sus aplicaciones estén siempre al día con las últimas versiones. Bit.dev también nos proporciona una visión general de todos los componentes en nuestros diferentes proyectos, de modo que podemos controlar y regular exactamente quién está utilizando qué componente en qué versión.


Nuestro proceso

La Ley de Conways afirma que existe una fuerte correlación entre la arquitectura del software y la estructura organizativa. Esto es muy cierto cuando se construyen micro frontales, ya que el objetivo principal es hacer que la organización sea más eficiente. Desacoplar las bases de código, habilitar las integraciones o dividir el proceso de lanzamiento son formas de construir un mejor software y equipos ágiles autónomos.


Equipos autónomos

Un equipo pequeño con capacidad para tomar decisiones y avanzar sin descanso hacia sus objetivos ofrecerá resultados y conocimientos mucho más rápidamente que un grupo más grande. Después de todo, ¿Quién conoce mejor a los usuarios y los problemas del producto que el equipo que lo posee, verdad?


Gracias a la flexibilidad de nuestra arquitectura basada en componentes, pudimos asignar la propiedad de los equipos y de una forma mucho más dinámica, vertical y relevante para el contexto. En lugar de tener un "equipo de front-end" para bit.dev y un "equipo de web de marketing" trabajando juntos en una aplicación monolítica, separamos completamente estos equipos en todos los sentidos.


Bases de código sencillas y desacopladas

El desacoplamiento de las bases de código facilita el desarrollo, las pruebas, el mantenimiento, la sustitución o la actualización de las funciones. En las que se añaden  continuamente nuevas tecnologías y funciones.


El código fuente de cada función o producto es, naturalmente, mucho más pequeño y sencillo que el de toda la aplicación, lo que hace que la base de código sea mucho más fácil de desarrollar, probar y mantener sin las limitaciones y los problemas de trabajar juntos dentro de un monolito.


Si vuelves a ver los ejemplos "base-ui" y "evangelist" en la página de inicio de bit.dev, te darás cuenta de que cada conjunto de componentes se desarrolla en una base de código diferente. Ambos conjuntos están desacoplados el uno del otro, y se integran juntos para crear diferentes páginas, características y aplicaciones.


Como todas las bases de código están desacopladas entre sí, y cada una está compuesta en su mayor parte, si no en su totalidad, por componentes, también resulta mucho (mucho) más fácil refactorizar gradualmente partes de nuestras aplicaciones, de modo que podemos añadir o sustituir tecnologías de forma rápida y segura.


Con el tiempo, tener que definir claramente qué código pertenece a cada base de código, es una gran manera de entender mejor la arquitectura que estamos construyendo, y el papel de cada parte dentro de ella.


Canalizaciones de publicación independientes

Podemos dividir y desacoplar el proceso de publicación de los distintos equipos, de modo que cada equipo pueda crear y publicar cambios en varias aplicaciones de forma independiente, sin tener que esperar a que las versiones crezcan o luchar por las ramas maestras.


Como se mencionó anteriormente, a través de Bit y Bit.dev somos capaces de asignar un pipeline de construcción personalizado pero estandarizado para el conjunto de componentes de cada equipo. Así, a pesar de ser construidos por separado, todos los componentes pueden pasar por las mismas tareas y herramientas.


Entonces, el proceso de CI (50 veces más rápido) impulsado por componentes en Bit.dev (en Beta) mapea y construye cambios en el gráfico de dependencia de propagación de todos los componentes dependientes a través de cada página y cada aplicación.


En palabras simples, cada equipo puede hacer un cambio en cualquier componente, construir independientemente estos cambios, y aprender si y cómo rompe otros componentes y otros equipos a través de todas las aplicaciones pertinentes.


Si todo está bien, los cambios se traducen automáticamente en una Pull-Request que se envía a todos los proyectos relevantes, para que sus propietarios puedan actualizar sus componentes. Incluso reciben notificaciones y recordatorios a través de Slack. En la función "Proyectos" de Bit.dev (otro de nuestros equipos), podemos ver y controlar quién adoptó qué PR y dónde.


Así, en lugar de complicarnos con engorrosos iframes o de buscar soluciones alternativas, nos apoyamos en integraciones en tiempo de compilación que no acoplan nuestros procesos de lanzamiento. Por ahora, esto funciona increíblemente bien para nosotros, y nuestro CI basado en componentes saldrá de la Beta dentro de unas semanas, así que no dudes en probarlo cuando salga también. En el futuro, tenemos un plan para ir hasta el final y habilitar los despliegues impulsados por componentes en las aplicaciones.


Más actualizaciones incrementales

Ahora que nuestra base de código se construye a partir de bases de código más pequeñas desacopladas, que se construyen con componentes modulares que se versionan de forma independiente, hemos obtenido una capacidad muy útil para añadir, sustituir, corregir o incluso revertir fácilmente un solo componente o característica.


Los equipos pueden tomar decisiones caso por caso, cambiar y entregar rápidamente actualizaciones y características, y tratar la refactorización como un proceso gradual en curso que puede hacerse pieza por pieza. Además, todo nuestro software se vuelve más resistente, ya que es casi imposible que los desarrolladores rompan cosas fuera del ámbito de sus componentes.


Una cosa que nos gusta especialmente es la capacidad de responder rápidamente a las peticiones de los usuarios. Cuando un desarrollador pide un nuevo entorno de compilación de componentes que soporte una determinada versión de Stencil, por ejemplo, se crean y se añaden en unas horas en lugar de semanas. Y, como gran parte de Bit es de código abierto, podemos facilitar que la gente amplíe o sustituya cualquier parte de su conjunto de herramientas por su cuenta. Esto hace que todo nuestro equipo sea mucho más eficiente.


Reutilización y colaboración infinita de componentes

Publicamos todos los componentes en Bit.dev. Allí todos nuestros equipos comparten, descubren, colaboran y reutilizan los componentes entre sí de forma divertida y eficaz.


Las características añadidas, como la documentación visual de los componentes, la búsqueda inteligente de componentes e incluso las simulaciones en vivo, ayudan a que todos nuestros componentes sean descubiertos, de modo que no tengamos que mantener ningún sitio web de documentación, registro o herramienta adicional.


Este sistema de colaboración facilita a los desarrolladores compartir el código, sugerir comentarios y garantizar la coherencia. Es agradable especialmente el hecho de que ayuda a los nuevos desarrolladores que se unen al equipo a acortar su curva de aprendizaje, ya que pueden encontrar y empezar a utilizar los componentes existentes para poder empezar a construir.


También es una forma útil de mejorar la colaboración entre los desarrolladores y otras partes interesadas, en donde ahora pueden ver todos los componentes.


Conclusión

Algunos dicen que los micro frontales no son más que un "buen modelo de componentes". Para nosotros, fue un buen modelo de componentes tanto como una mejor manera de construir nuestro propio equipo, mejorar la forma en que trabajamos, construir un mejor software modular, y entregarlo más rápido y más a menudo.


Para las organizaciones más grandes, la entrega de equipos independientes es un verdadero cambio de juego en su capacidad para construir y enviar aplicaciones web exitosas. También lo es la capacidad de estandarizar el desarrollo de componentes y permitir que los equipos compartan y colaboren entre sí.


Para los equipos más pequeños, la adopción de una arquitectura flexible y escalable mejorará su capacidad de crecimiento, de añadir rápidamente nuevas características, de incorporar nuevas personas y de centrarse en la tecnología principal y en la innovación en lugar de en cosas menos importantes.


Espero que encuentres algo en la idea de los micro frontends basados en componentes que pueda serte útil, y ¡Gracias por leer!


Reactions

4

0

0

1

Access hereTo be able to comment

TheWhiteCode.com is not the creator or owner of the images shown, references are: