Nuestro Viaje hacia los Micro-Frontends

Rate this content
Bookmark
Slides

Construir productos utilizando Desarrollo Dirigido por Pruebas con React y Diseño Atómico se ha convertido en mi modus operandi a lo largo de los años. Algunos productos tienden a volverse más complejos y es crucial tener un buen flujo de trabajo para mantenerlos saludables y escalables. Ha llegado el momento de agregar otro jugador al juego: los Micro-Frontends. Esta charla compartirá un ejemplo práctico de esta configuración, algunas lecciones aprendidas y los obstáculos que se encontraron en el camino.

FAQ

Rita es una apasionada de la tecnología, desarrolladora de software y trabaja para Volkswagen Digital Solutions en Lisboa.

El equipo de Rita enfrentó el desafío de integrar nuevas características complejas desarrolladas por un subequipo, los Eagles, en el producto existente manejado por otro subequipo, los Falcons, asegurando una colaboración eficiente entre ambos.

Consideraron la implementación de microfrontends, una solución arquitectónica que permite una mejor modularidad y colaboración entre equipos independientes.

Un microfrontend es una arquitectura de desarrollo donde la aplicación frontal se divide en partes más pequeñas e independientes, cada una gestionada por diferentes equipos, lo que facilita la entrega y actualización de características.

El equipo de Rita creó una prueba de concepto seleccionando diferentes tecnologías y empaquetadores para demostrar que podían funcionar juntos en una aplicación ensamblada, utilizando React para mantener la simplicidad.

Los microfrontends permitieron implementaciones más fluidas, mayor autonomía de los equipos, y facilitaron la colaboración y entrega de productos, mejorando la experiencia del usuario final.

El equipo encontró desafíos relacionados con la transición a AWS, incluyendo políticas de seguridad y restricciones de red que complicaron el proceso de obtener e implementar los microfrontends como deseaban.

La adopción de microfrontends ayudó a identificar y resolver deudas técnicas tanto en el frontend como en el backend, permitiendo también adoptar un enfoque de microservicios en el backend.

Rita Castro
Rita Castro
11 min
06 Jun, 2023

Comments

Sign in or register to post your comment.

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.

Available in English: Our Journey Into μFrontends

1. Micro-frontends and the Falcons and Eagles

Short description:

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

Short description:

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.