Video Summary and Transcription
Bienvenidos a nuestro viaje hacia los micro-frontends. Integramos productos utilizando una dependencia llamada el rastreador de tarjetas. El proceso manual entre equipos planteó preguntas sobre el control de versiones. Los micro-frontends proporcionaron una experiencia de desarrollo fluida y permitieron la limpieza de la deuda técnica. El enfoque también abrió el camino para un enfoque de microservicios en el backend.
1. Micro-frontends and the Falcons and Eagles
Bienvenidos a nuestro viaje hacia micro-frontends. Mi nombre es Rita, una apasionada de la tecnología y desarrolladora de software en Volkswagen Digital Solutions en Lisboa. Permíteme contarte una historia sobre los Falcons y los Eagles, y cómo integramos sus productos utilizando una dependencia llamada el rastreador de tarjetas. Funciona.
Bienvenidos a nuestro viaje hacia los micro-frontends. Vamos allá.
Mi nombre es Rita. Soy una apasionada de la tecnología. También soy una ávida coleccionista de etiquetas, pintora de mandalas, maestra de Kirby y King Dedede. Estoy totalmente convencida de usar mi bicicleta para ir a todas partes en la ciudad. Madre de Pedro. Tiene cuatro años, le gustan los legos, a mí también, todo va genial. También soy desarrolladora de software y trabajo para Volkswagen Digital Solutions en Lisboa. Este es el increíble equipo con el que trabajo. Anteriormente en la React Summit, ya les he contado un poco sobre cómo construimos nuestros productos en el SDC. Si no lo han visto, por favor vayan y échenle un vistazo. Pero me gustaría agregar un poco más a esa historia. Así que aquí va. Érase una vez, mientras los Falcons construían y entregaban sus productos, realizaron mucha investigación de usuarios. Y a través de esa investigación de usuarios, identificaron que los distribuidores estaban interesados en una nueva característica, algo que les brindaría mucho valor. Pero esta nueva característica era lo suficientemente compleja y grande como para que pudiera ser desarrollada por su propio equipo. Así nacieron los Eagles. Pero no era realmente suficiente que los mismos usuarios finales tuvieran dos productos diferentes que se utilizaran esencialmente. Así que decidimos, bueno, nos gustaría que lo que los Eagles están construyendo se integre en lo que los Falcons ya están entregando. ¿Cómo podríamos hacer esto? Bien, decidimos, muy bien, los Eagles crearán una dependencia, el rastreador de tarjetas, que se publicará en un registro privado al que podemos acceder, y luego los Falcons irán y lo instalarán. Bien, parece un buen arreglo. Así que establecimos un flujo de trabajo entre los dos equipos. En primer lugar, los Eagles, hacen commit, hacen push, esencialmente, desarrollan y dan vida al producto. Aumentan la versión de su package.json para controlar en qué versión estamos, sin embargo. Luego publicamos esta dependencia y esperamos a que se ejecute un pipeline. Y esperamos, esperamos, esperamos, pero el trabajo no termina aquí. ¿A dónde va? Va a los Falcons. En el lado de los Falcons, necesitas aumentar la versión del rastreador de tarjetas en su package.json para obtener una instalación nueva y fresca, pero también necesitas hacer commit y push para que puedas
2. Challenges with Manual Process
El proceso manual entre los dos equipos planteó varias preguntas. ¿Quién se encargaría de aumentar la versión en el lado de los Falcons? ¿Cómo lo rastreamos a través del backlog? ¿Deberían los Eagles aumentar la versión cada vez que construyamos algo? Estas preguntas existían solo para un ecosistema con dos equipos, y cuanto más grande sea el equipo, más preguntas y problemas surgirían.
desencadenar los cambios en el pipeline y la nueva característica cobra vida. Funciona. Era funcional, pero había varios problemas. En primer lugar, era un proceso manual, por lo que había algunos pasos entre los dos equipos que necesitaban estar sincronizados. Inevitablemente, surgen preguntas, ¿qué más podría fallar? Publicamos, ¿no es así, lo que sea? Pero sobre todo y lo más importante, ¿quién se encargaría de aumentar la versión en el lado de los Falcons? Y sobre todo, ¿cómo lo rastreamos a través del backlog? ¿En qué backlog, el de los Eagles o el de los Falcons? Tienes que sincronizarlo. ¿Y deberían los Eagles aumentar la versión cada vez que construyamos algo? ¿Y cada vez que entreguemos, deberíamos aumentarla? Preguntas. Y estas son preguntas que existían solo para un ecosistema con dos equipos. Por lo tanto, cuanto más grande sea el equipo, más grandes y más preguntas tendrás y más problemas.
3. Microfrontends as a Solution
Queríamos una experiencia de desarrollo fluida para los Falcons, Eagles y otros equipos. Los microfrontends parecían ser una posible solución. Después de investigar y crear una prueba de concepto, elegimos usar React como nuestra estructura de la aplicación. Integramos los microfrontends en una imagen más grande y replicamos nuestro producto.
que enfrentarías. ¿Qué queríamos? Queríamos tener una experiencia de desarrollo que fuera completamente fluida, que pudiera incluir a los Falcons, los Eagles y cualquier otro que quisiera unirse. Poder entregar y desarrollar sus productos de manera fluida y proporcionar una buena interacción hacia el usuario final. Así que estábamos un poco atascados. Pero en octubre de 2021, surgió una nueva esperanza. Cuando visité React Advanced, conocí a Alex y Ruben. Estaban hablando sobre microfrontends en sus charlas y también en los paneles. Así que hubo muchas discusiones y aprendí mucho. Y surgió una pequeña pregunta. ¿Podría ser que los microfrontends fueran la solución arquitectónica que podríamos usar para solucionar nuestro problema con los Eagles y los Falcons?
Al regresar a Londres, a Lisboa, leímos mucho. Leímos algunos libros, hicimos preguntas a Google y pensamos, bueno, ahora sabemos y ya se sabía en ese momento que los microfrontends se crearon utilizando los mismos principios. Por lo tanto, derivan de los mismos principios que los microservicios. Entonces, ¿en qué punto estamos con nuestro ecosistema? Tenemos equipos independientes. Así que está descentralizado. Todo bien. Tenemos un enfoque claro en el cliente, por lo que podemos modelar nuestros negocios o nuestros dominios en torno a los negocios. Tenemos el CI/CD. Por lo tanto, la automatización y la implementación están cubiertas. Pero queríamos tener esas implementaciones fluidas para que los equipos independientes realmente construyeran y entregaran software. Así que veamos si podemos lograrlo. Creamos una prueba de concepto y con esa prueba de concepto, comenzamos desde tener un conjunto de diseños e identificar diferentes microfrontends ellos. Elegimos mezclar y combinar empaquetadores y tecnologías para demostrar también a nosotros mismos que no importa qué conjunto de tecnologías uses para tu microfrontend, siempre y cuando publiques tus resultados. Y eventualmente, el microfrontend es completamente inútil por sí solo, casi. Prospera cuando se integra en una imagen más grande , por lo que debes ensamblarlo en algún lugar. Y para nosotros, la elección fue ensamblarlo en una estructura de la aplicación. Y esta estructura de la aplicación se creó utilizando solo React. ¿Por qué? Porque no queríamos pasar mucho tiempo aprendiendo y probando todos los frameworks que existen para ensamblar microfrontends. Así que vamos con React. Mantengámoslo simple y veamos hasta dónde podemos llegar. Y eso hicimos. Obtenemos los resultados del empaquetado anterior desde la nube, gracias
4. Deploying Microfrontends and Lessons Learned
Desplegamos con éxito nuestra arquitectura de microfrontends utilizando React sin necesidad de frameworks adicionales. Aunque enfrentamos desafíos con AWS y la definición de los límites entre los microfrontends, aprendimos lecciones valiosas y logramos implementaciones fluidas. Este enfoque también nos permitió limpiar la deuda técnica y allanar el camino para un enfoque de microservicios en el backend. En general, estamos satisfechos con los resultados y creemos que los microfrontends tienen nuestro sello de aprobación.
Docker, y replicamos lo que sería nuestro producto real. Estábamos convencidos de que esto funcionaba, así que vamos por el producto real. Eso comenzó exactamente de la misma manera. Tomamos los diseños de Figma. Identificamos los microfrontends que queríamos. A partir de nuestra prueba de concepto, entendimos que la mejor combinación es tener ES build y React. Es extremadamente rápido, es realmente genial, pero la gran diferencia es que ahora estábamos implementando en AWS. Entonces, si implementas en AWS, colocas tus resultados en un bucket de S3, todo bien. Y repetimos el patrón para los microfrontends que necesitábamos construir. También mantuvimos el patrón de una app shell que se construyó utilizando React, también en AWS, que obtendría los microfrontends de los buckets de S3. Con esta configuración, lanzamos, avanzamos con el producto y aprendimos mucho en el camino durante el desarrollo. ¿Qué aprendimos? Bueno, aprendimos que tuvimos experiencias realmente buenas, tuvimos cosas locas y tuvimos cosas malas. Vamos a dejar eso de lado. AWS fue un poco desafiante porque fue un momento de transición, estábamos cambiando nuestra infraestructura, el equipo era nuevo en AWS. Por sí solo, ya era desalentador. Pero como puedes imaginar, trabajando para VW, tienes muchas políticas y muchas restricciones de seguridad en la red. Entonces eso planteó un problema al tratar de obtener cosas y tener las cosas en funcionamiento como queríamos. Pudimos hacerlo, pero nos llevó tiempo. ¿Cuándo trazar la línea entre los microfrontends? Esto fue algo que solo entendimos un poco durante el desarrollo y, esencialmente, es porque no identificamos de manera clara cuáles serían nuestros objetos de dominio. Entonces necesitábamos tener un poco más de claridad, no claridad, lo siento. Necesitábamos tener un poco más de visión sobre cuáles serían los objetos que se compartirían entre los microfrontends. Y esto va un poco junto con el sistema de diseño, porque, bueno, tenemos un sistema de diseño establecido. Pero a veces tienes que hacer un pequeño ajuste aquí en este micro frontend y luego otro pequeño ajuste en el otro micro frontend. ¿Dónde lo pones, lo duplicas? Era un poco confuso. Otra pregunta, ¿usar un monorepo o usar un repositorio por micro frontend? Las opiniones están dispersas. No tenemos una opinión sólida, pero es algo que nos preguntamos, ¿hemos hecho lo correcto? ¿Deberíamos hacerlo de manera diferente? No lo sabemos. Sin embargo, lo que sí sabemos es que React salió adelante. Así que pudimos entregar e implementar una arquitectura de micro frontend utilizando solo React. No se necesitó ningún framework y está funcionando. Así que felicitaciones. En este proceso, como abordamos el producto como uno nuevo, pudimos limpiar mucho de la deuda técnica, por supuesto, no solo en el frontend, naturalmente, sino también en el backend, porque pudimos identificar algunos lugares donde no tomamos las mejores decisiones en el pasado y ahora hemos allanado el camino también para adoptar un enfoque de microservicios en el backend. Sobre todo, hemos logrado las implementaciones fluidas que queríamos. Tenemos equipos independientes trabajando juntos, entregando y brindando la mejor experiencia al usuario final de manera autónoma. En general, diría que los microfrontends tienen nuestro sello de aprobación. Así que muchas gracias. Nos vemos pronto. Adiós.
Comments