Video Summary and Transcription
Esta charla explora la migración y actualización de una Biblioteca de Componentes en Vue y Nuxt. Se inspira en las grandes migraciones de la naturaleza y enfatiza la necesidad de colaboración y compatibilidad. La charla discute la configuración del equipo, incluyendo microservicios y módulos estandarizados. Destaca la migración de Vuex a Pina o Apollo Clients en micro frontends. Se enfatiza el enfoque distribuido para mantener la biblioteca de componentes, así como el uso de Vue Demi para la actualización a Vue 3. La charla enfatiza la importancia de entregar valor y soportar tanto Vue 2 como Vue 3 en el proceso de migración.
1. Introducción a las migraciones y la biblioteca de componentes
Gracias por acompañarme hoy en esta charla sobre grandes migraciones y la actualización de la biblioteca de componentes. Compartiré una historia que funciona para nuestra organización y puede inspirarte a aplicar enfoques similares en tu propia empresa. Estaremos actualizando y migrando todo lo construido en Vue y Nuxt. Comencemos. Mi nombre es Johan, soy un desarrollador front-end en Yumbo. No dudes en contactarme si tienes alguna pregunta.
Muy bien. Así que, gracias por acompañarme hoy en esta charla sobre grandes migraciones, la actualización de esta cosa llamada biblioteca de componentes. Y lo que voy a contar o la historia que voy a compartir es algo que funciona para nosotros, para nuestra organización, y no necesariamente se aplica directamente a tu organización, pero espero que puedas tomar algo de inspiración o algunas partes de ella para aplicar en tu propia empresa u organización. Y lo que dice, biblioteca de componentes, aquí en el título, se trata básicamente de todo el entorno que tenemos porque todo lo que tenemos está construido en Vue y Nuxt. Así que estaremos actualizando y migrando todo básicamente durante esta charla, si tienes paciencia conmigo. Así que mi nombre es Johan. Como puedes ver, soy un desarrollador front-end. Trabajo para Yumbo. Explicaré un poco más adelante qué es eso. Puedes encontrarme en Twitter, puedes encontrarme en Mastodon o en mi página web personal. Si tienes alguna pregunta relacionada con este tema u otro tema, no dudes en contactarme después de esta presentación o simplemente charlar conmigo sobre
2. Ejemplos de migración en la naturaleza
Esta presentación está inspirada en la serie de la BBC sobre los grandes eventos de la naturaleza, en particular el episodio de la gran migración. Exploraremos diversas migraciones y aprenderemos de ellas. La migración de los ñus es la más grande, con más de un millón de bestias recorriendo 1800 millas. Los caribúes tienen la ruta de migración más larga, cubriendo 3100 millas cada año. Las hormigas de fuego colaboran para atravesar el agua, mientras que los desarrolladores enfrentan desafíos como el traslado de requisitos y las infestaciones de errores. Investigaremos patrones para optimizar la migración y definiremos la migración como un período de movimiento.
estos temas. Ahora, toda esta presentación está inspirada en la serie de la BBC sobre los grandes eventos de la naturaleza, y en este caso particular, el episodio de la gran migración. Aquí puedes ver una imagen de un joven David Attenborough lidiando con algo que se asemeja a un lagarto o algo así. Solía ver esta serie cuando era más joven, generalmente con mi padre, así que tengo muy buenos recuerdos de esta serie, y por eso creo que tiene una buena analogía con lo que hacemos en el desarrollo de software. Veremos cómo lo hacen los expertos en la naturaleza, migrando, y qué podemos aprender de ello en nuestro trabajo diario. Así que elegí un par de migraciones que destacan por diversas razones, y echemos un vistazo a ellas. Creo que la más famosa es, por supuesto, la migración de los ñus. He anotado algunas cosas al respecto porque no conozco todos los detalles de memoria, pero esta es la migración más grande que existe. En realidad, es una supermanada formada por ñus, cebras y gacelas, y migran con un millón o más de un millón de bestias. Realizan un viaje de 1800 millas o 2900 kilómetros, y es un viaje de ida y vuelta desde Tanzania hasta Kenia y de regreso. Y mientras hacen esto, con la escala masiva que tienen, en realidad juegan un papel en la formación o ajuste del paisaje. Así de grande es esto. Y tienen que atravesar ríos infestados de cocodrilos. Tienen que superar sequías. Son presa de leones, y lo que realmente están haciendo es criar crías mientras migran. Si observamos la analogía, en realidad están implementando cosas en producción mientras migran. Creo que esto es realmente interesante e impresionante.
Luego tenemos a los caribúes o renos, como quieras llamarlos, y tienen la ruta de migración más larga que tenemos en tierra. Cubren hasta 3100 millas o 5000 kilómetros cada año y se mueven desde sus áreas de apareamiento hasta sus áreas de cría en primavera. Y luego regresan a sus áreas de invernada durante el otoño en un patrón circular. Por lo tanto, el momento y la distancia de esas migraciones pueden variar según ciertos factores como el clima, la disponibilidad de alimentos y agua, y el riesgo de depredadores. Esta es la migración más larga.
Y luego tenemos, esto es una colaboración máxima, tenemos las hormigas de fuego en los bosques de Brasil, en las selvas tropicales, y pueden formar grupos de más de 100,000 hormigas que se aferran entre sí y lo hacen para atravesar el agua. Y esto es una forma interesante de moverse, ¿verdad? Son expertas en colaborar y las hormigas en la parte inferior de este grupo deben aferrarse con todas sus fuerzas para evitar ser sumergidas, mientras que las que están en la parte superior corren el riesgo de ser comidas por aves y otros depredadores. Y luego está la última pieza del rompecabezas. Este es el esquivo grupo de desarrolladores y típicamente se mueven en equipos de varios tamaños y tienen que lidiar con otros peligros como el traslado de requisitos, implementaciones los viernes e infestaciones de errores, y caídas del sistema. Por lo que investigaremos patterns para optimizar la migración patterns y veremos si podemos aprender algo de la naturaleza. Comencemos con una definición. Entonces, ¿qué queremos decir con migración? Y para esta charla, consideremos esto. Es un período porque no sucede instantáneamente, lleva tiempo y esfuerzo de movimiento. Bueno,
3. Razones para migrar
Grandes volúmenes porque no se trata solo de una gacela mirando qué hay al otro lado del valle, qué está pasando allí. Se trata de un grupo. Y vamos de un punto A a un punto B porque tenemos un trabajo que hacer en el punto B, ¿verdad? Esta es la definición que utilizaremos. Y ¿por qué migrar? Siguen el rastro hacia áreas de alimentación abundante. Y si no lo hicieran, el entorno en el que viven no sería capaz de mantener la manada o soportar el número de individuos. Así que morirían una muerte horrible. Y la analogía en el software es que queremos tener soporte para nuestro software, por supuesto. Y, por supuesto, no se trata realmente de seguir el almuerzo y el café. Se trata de la capacidad de implementar rápidamente nuevas características en producción y tener estabilidad en el entorno para lanzar con confianza. Esa es una buena razón para migrar. Así que eso es por qué estamos haciendo esto. Después de esta analogía tonta, investiguemos. Y lo que haremos es observar un patrón migratorio en un entorno relativamente aislado, y ese es el lugar salvaje de YUMBO. Y donde estamos haciendo esto es el campus tecnológico de YUMBO o JTC, como lo llamamos, y hay más de 450 desarrolladores que colaboran en la construcción de nuestros productos digitales. Ahora que hemos conocido a los guardianes de la manada, es hora de echar un vistazo a la manada y al paisaje.
La migración puede ser cualquier cosa, desde hormigas hasta personas o incluso código. Grandes volúmenes porque no se trata solo de una gacela mirando qué hay al otro lado del valle, qué está pasando allí. Se trata de un grupo. De lo contrario, no tendría mucho sentido. Y vamos de un punto A a un punto B porque tenemos un trabajo que hacer en el punto B, ¿verdad? Esta es la definición que utilizaremos.
Y luego está la pregunta, ¿por qué migrar? Y si observamos a los ñus, tienen una muy buena razón. Siguen el rastro hacia áreas de alimentación abundante. Y si no lo hicieran, el entorno en el que viven no sería capaz de mantener la manada o soportar el número de individuos. Así que morirían una muerte horrible. Y la analogía en el software es que queremos tener soporte para nuestro software, por supuesto. Así que si observamos la vida de un ñu, no es realmente una vida bonita, pero está en constante movimiento. Veamos cómo podemos aplicar esto a nosotros. Y, por supuesto, no se trata realmente de seguir el almuerzo y el café. Se trata de la capacidad de implementar rápidamente nuevas características en producción y tener cierta estabilidad en el entorno para lanzar con confianza. Ahora, esta estabilidad es algo opuesto a la migración y hay un riesgo aquí, al igual que los ñus enfrentan, esos ñus probablemente estarían mejor si simplemente se quedaran en sus áreas de alimentación. No tendrían que cruzar esos ríos. Tendrían poco riesgo si se quedaran, pero tienen una razón para hacer esto y todo se trata de recursos. Para ellos, es comida. Y para nosotros, los desarrolladores, es el soporte de la plataforma, como dije. Así que combinemos ese soporte con una mejor experiencia de desarrollo y la capacidad de crear nueva estabilidad. Esa es una buena razón para migrar. Así que eso es por qué estamos haciendo esto.
Después de esta analogía tonta, investiguemos. Y lo que haremos es observar un patrón migratorio en un entorno relativamente aislado, y ese es el lugar salvaje de YUMBO. Entonces, si no eres de los Países Bajos o Bélgica, probablemente nunca hayas oído hablar de esto o de nosotros, pero somos una cadena de supermercados y hacemos muchas compras en línea. En realidad, estamos en la cima de los Países Bajos y Bélgica. Y desarrollamos gran parte de nuestro software internamente. Y donde estamos haciendo esto es el campus tecnológico de YUMBO o JTC, como lo llamamos, y hay más de 450 desarrolladores que colaboran en la construcción de nuestros productos digitales. Y esto no es la manada. Estos son los guardianes de la manada, y necesitan asegurarse de que nuestra manada de software o código llegue al punto B de manera segura. Ahora que hemos conocido a los guardianes de la manada, es hora de echar un vistazo a la manada y al paisaje.
4. Migración de comercio electrónico y configuración del equipo
Hemos estado transfiriendo gradualmente la responsabilidad de nuestro motor de comercio electrónico a aplicaciones específicas de Vue.js y Nuxt. Nuestra configuración de equipo involucra responsabilidad individual para diferentes dominios, con aplicaciones de Nuxt o Vue dependiendo de microservicios. También tenemos módulos y complementos estandarizados para tareas genéricas, microaplicaciones para cumplir con los procesos de comercio electrónico y una biblioteca de componentes con cientos de componentes. La necesidad de migrar surge del anuncio de Vue 3 y Nuxt 3, junto con el fin de vida de Vue 2. Hemos trazado un camino de migración basado en dependencias y cuellos de botella, siendo los cuellos de botella los cruces de ríos que debemos superar.
Echemos un vistazo a la manada y al paisaje. Ahora, entre otras cosas, tenemos un gran motor monolítico de comercio electrónico, que ha estado en funcionamiento durante más de una década, creo. Y lo que hemos estado haciendo con el tiempo es comenzar a transferir un poco de la responsabilidad del motor de comercio electrónico a aplicaciones más específicas de Vue.js y Nuxt. Y comenzamos a involucrarnos con Vue al comienzo del lanzamiento de V2, por lo que llevamos bastante tiempo haciéndolo. Y gradualmente agregamos Nuxt para mitigar o migrar un poco del monolito a su dominio o aplicaciones y grupos específicos.
Y lo que tenemos aquí es una configuración de equipo donde los equipos son responsables individualmente de su propio dominio. Y si nos acercamos un poco más, podemos echar un vistazo a cómo podría ser una configuración de equipo típica. Entonces, esta podría ser una configuración de equipo típica. Puede variar en complejidad de un equipo a otro, pero esto es lo que normalmente se esperaría. Entonces, hay una aplicación de Nuxt en el centro. Eso también podría ser una aplicación de Vue. Y eso depende de algunos microservicios. Eso podría ser RESTful o GraphQL o Apollo. Realmente no nos importa porque eso es parte de la responsabilidad del equipo. Y luego, en términos de comercio electrónico, la mayoría de las aplicaciones de Nuxt dependen de un par de módulos y complementos estandarizados que desarrollamos, y se ocupan de cosas genéricas, como análisis y seguimiento. Y así, solo ayudan a la aplicación de Nuxt con cosas genéricas. Y luego, en términos de facilitar las necesidades del cliente, si servimos la base, también incluimos algunas microaplicaciones para cumplir con el proceso de comercio electrónico. Y un ejemplo de esto podría ser el Carrito, que es una aplicación aislada, que se adjunta a la interfaz de usuario de esa aplicación de Nuxt. Y por último, tenemos una biblioteca de componentes. Y eso simplemente contiene cientos de componentes que construyes o usas para construir interfaces de usuario, lo cual creo que es un enfoque sensato. Si imaginas esta configuración con diferentes tipos de complejidades distribuidas en la empresa, tendrás una idea decente de cómo se ve nuestra manada. Entonces, esta es la manada que necesitamos mover, porque todo esto se hace en Vue 2 con Nuxt 2. Así que necesitamos actualizar. Necesitamos migrar. Y esto se debe a que, por supuesto, el año pasado se anunciaron Vue 3 y Nuxt 3, pero también se anunció el fin de vida de Vue 2. Así que es cuando nos quedamos sin recursos, más o menos. Esta es la razón por la que necesitamos migrar. Y ahora que tenemos una muy buena razón para hacer esto, necesitamos una dirección general o un camino de migración. Y con todo nuestro conocimiento combinado, comenzamos a trazar un camino de migración basado en las dependencias y los cuellos de botella que pudimos identificar. Y en términos de la analogía del ñu, los cuellos de botella podrían considerarse los cruces de ríos que debemos superar para avanzar.
5. Migración de Micro Frontend
Estamos migrando de VueX en nuestros micro frontends para admitir entornos de Vue 3. El equipo responsable de la cesta está eliminando la API de VueX y adoptando un enfoque tecnológicamente agnóstico para interactuar con la cesta. Están pasando a Pina o Apollo Clients, eliminando la dependencia de VueX y permitiendo a todos actualizar.
Y uno de los primeros y más importantes cuellos de botella o cruces de ríos que debemos superar son esos micro frontends. Entonces, lo que hicimos en el pasado, lo que estamos haciendo actualmente migrando de esto, es que tenemos estos micro frontends y básicamente son aplicaciones de vista que adjuntamos al DOM. Y están utilizando VueX para mutar y modificar el funcionamiento interno de esa micro aplicación, como agregar productos a una cesta, eliminarlos o actualizar la cantidad. Y eso es algo de lo que necesitamos deshacernos, porque ya no queremos admitir VueX en entornos de Vue 3. Entonces, lo que en este caso está haciendo el equipo responsable de la cesta, es que están eliminando toda la API de VueX. Y, por supuesto, tener una API de VueX para operaciones públicas puede considerarse algo arriesgado, pero nos funcionó. Pero están pasando a una forma más tecnológicamente agnóstica de interactuar con la cesta. Internamente, están pasando a Pina o a Apollo Clients, si no me equivoco. Pero básicamente están eliminando la dependencia de VueX, lo que permite que todos los demás también actualicen, porque mientras tengan VueX, todos dependen de esto. Así que ya estamos cruzando el río en este momento.
6. Compatibilidad de Módulos y Colaboración
Al igual que el Auxbacker soporta nuestras aplicaciones NUXT, tenemos módulos que se encargan de tareas como analítica y SEO. Los equipos que utilizan estos módulos y complementos colaboraron para garantizar la compatibilidad con NUXT 3, ya sea reescribiéndolos o creando envoltorios. Esto nos permite avanzar.
Y luego tenemos, al igual que este Auxbacker está soportando. Este es un búfalo de agua, en realidad, no un ñu. Pero al igual que este Auxbacker desempeña un papel de apoyo en nuestras aplicaciones NUXT, tenemos módulos. Y esos módulos, como dije, se ocupan de cosas como recopilar análisis o asegurarse de que el SEO cumpla con las especificaciones. Y lo que hicimos aquí es, porque no todos dependen de ellos, hemos reunido a los equipos que utilizan estos módulos y complementos y cada equipo individual se sentó juntos, y o bien reescribieron el módulo y complemento para que sean compatibles con NUXT 3, en este caso, o escribieron envoltorios, o simplemente lo reescribieron por completo para que todos puedan avanzar. Así que una vez más, estamos cruzando otro río aquí.
7. Component Library and Distributed Approach
Esta oruga representa Vue 2 y necesita transformarse en una mariposa compatible con Vue 3. Nuestra biblioteca de componentes, construida en Vue, se mantiene a través de un enfoque distribuido donde cada desarrollador puede contribuir. Permitir que los usuarios modifiquen la biblioteca crea una inversión y asegura que todos se preocupen por ella. El conocimiento distribuido mitiga el riesgo de perder experiencia. Los equipos contribuyen y crean espacio para que otros avancen. Una vez que un gran grupo ha cruzado, toda la manada puede avanzar. Las mejoras se comparten en toda la organización. Ajustamos la biblioteca de componentes para admitir Vue 2.
Y finalmente, esto es un desafío porque esta oruga representa Vue 2 y necesita transformarse en una hermosa mariposa compatible con Vue 3, el problema es que necesitamos mantener viva a la oruga hasta que todos los demás hayan podido migrar. Así que aquí hay un desafío y vamos a echar un vistazo a la biblioteca de componentes de manera más específica. Entonces, nuestra biblioteca de componentes. Esto es algo que construimos hace un par de años y contiene cientos de componentes. Lo construimos en Vue, por supuesto. Usamos Storybook para la documentación. Así que es un enfoque sensato. Y la forma en que estamos manteniendo y colaborando en nuestra biblioteca de componentes es lo que llamamos un enfoque distribuido. Esto significa que cada desarrollador que tiene un interés en la biblioteca de componentes puede contribuir o colaborar en agregar nuevas características, realizar mantenimiento y mantenerla en muy buen estado. Y discutiré estos cuatro temas más adelante.
Así que primero echemos un vistazo a esta inversión. Creo que este es el factor más importante o la decisión que tomamos, y es que todos los usuarios pueden modificar la biblioteca. Y esto es importante porque creo que esto crea una inversión en la biblioteca y asegura que todos se preocupen por ella. Es como un cuidado, si miras esta imagen, asegurándote de que todo esté en perfecto estado y sea responsabilidad de todos. Y creo que esto es clave para todas las demás cosas que hacemos. Y luego, a veces sucede que los encargados por alguna razón abandonan la manada. Y si haces esto, si lo haces con un equipo pequeño, tengo que decir, entonces existe el riesgo de que mucho conocimiento abandone tu manada o tu empresa u organización. Y nuevamente, al tener este enfoque distribuido, también hemos distribuido el conocimiento sobre nuestra biblioteca de componentes, lo que significa que si alguien se va por cualquier motivo, la pérdida de conocimiento no es tan grande y el riesgo se mitiga entre todos los demás colaboradores. También crea una especie de estímulo para que todos sigan compartiendo su conocimiento, lo cual creo que también es clave para asegurarnos de que mantengamos todo actualizado y que todos estén en la misma página. Y luego, al igual que estos ñus están cruzando el arroyo, lo que hacen con su cuerpo es que alguien avanza y ese cuerpo crea espacio para que otro ñu se mueva hacia ese hueco y también avance. Entonces, están bloqueando el arroyo para ayudar a otros a cruzar. Y no quiero centrarme en la parte de bloqueo aquí, pero lo que sucede es que crean espacio para que otros equipos avancen o para que otros ñus avancen. Y no es muy diferente con nuestro modelo distribuido. Cada equipo aquí contribuye y avanza, lo que crea espacio para que otros equipos también avancen y aceleren. Creo que este también es un beneficio clave de tener este enfoque. Una vez que hemos cruzado ese río, toda nuestra manada puede avanzar. Y así esperamos hasta que un gran cuerpo de código o animales haya cruzado antes de enfrentar el próximo desafío o problema. Además, cualquier mejora que hagamos se comparte de inmediato en toda la organización, lo que hace que todos, incluso los BO, estén felices, todos se benefician. Entonces, una vez que cruzas ese río, todos pueden avanzar. Podríamos ajustar más la biblioteca de componentes.
8. Enfoque y Progreso
Utilizamos Vue Demi para acercar nuestra aplicación de Vue 2 a Vue 3. Estamos actualizando microaplicaciones y la biblioteca de componentes. Nos aseguramos de que los nuevos proyectos no dependan de software heredado y hacemos que las API sean más agnósticas en cuanto a tecnología. Nuestra dirección común y enfoque incremental nos ayudan a entregar valor en el camino. Apoyamos tanto Vue 2 como Vue 3 para asegurarnos de que nadie se quede atrás. Al cliente no le importa la versión, solo quiere sus productos de supermercado. Nuestro enfoque distribuido nos permite migrar y entregar características simultáneamente.
Migrar la biblioteca de componentes de Vue 2 a Vue 3 porque también necesitábamos admitir Vue 2. Y lo que hicimos aquí es usar Vue Demi para acercar nuestra aplicación de Vue 2 lo más posible a Vue 3. Luego comenzamos a colocar un nuevo paquete compatible con Vue 3 junto al paquete de Vue 2 para poder admitir ambos. Ahora, si miramos dónde estamos ahora mismo, aún no hemos llegado, pero ya hemos superado muchos ríos infestados de cocodrilos en este caso. Lo que estamos haciendo o lo que aprendimos es que vamos a comenzar nuevos proyectos si no tienen dependencias de software heredado en Vue 3 y NUXT 3 para asegurarnos de que ya estén preparados para nuestro próximo paso.
También nos aseguramos de que si tenemos alguna API que dependa de una pila tecnológica específica, como en el caso de VueX, en el caso de la cesta, ahora nos aseguramos de que sea un enfoque más agnóstico en cuanto a tecnología para que tengamos las API listas, pero todo lo relacionado con la tecnología se haga dentro de la aplicación, por lo que ya no tiene dependencias externas. Actualmente estamos en proceso de actualizar esas microaplicaciones y la biblioteca de componentes, así que estamos en buen camino. Esto significa que nuestra manada ha encontrado pastos verdes nuevamente, superando los desafíos como equipo. Aunque aún no hemos llegado, estamos acortando la brecha. Creo que es bueno compartir estas lecciones que hemos aprendido durante nuestro viaje. Existe esta dirección común. Es realmente importante saber a dónde quieres ir y también lo que necesitas hacer para llegar allí. Esto realmente nos ayudó a trazar todo nuestro camino y esos incrementos se aseguran de que tengamos los entregables en el camino y agregan valor una vez que se lanzan o se completan. Puedes pensar en esos complementos que ya son compatibles con NUX 3, lo que asegura que ya podamos comenzar a construir proyectos de NUX 3 para nuevos proyectos de andamiaje. Asegurarnos de que nadie se quede atrás básicamente significa que estamos apoyando todo lo que aún depende de Vue 2 hasta que nuestro último equipo o aplicación esté listo para dar el salto a Vue 3. Y esto es por qué estamos haciendo esto con la biblioteca de componentes, para admitir ambos, porque al final, todo lo que entregamos lo hacemos por el cliente. Y al cliente realmente no le importa si estamos usando Vue 2 o Vue 3, solo quiere comprar sus productos de supermercado. Así que nos aseguramos de que nuestros equipos puedan entregar esas características. Y este enfoque distribuido que expliqué un poco asegura que podamos seguir entregando características a producción. Es como la cría de vacas en la manada salvaje mientras trabajamos en nuestra migración. Así que estamos migrando y entregando al mismo tiempo. Y creo que eso también es muy importante para asegurarnos de que no estamos bloqueando ninguna característica mientras hacemos esto porque es un esfuerzo tan grande. Me gustaría cerrar con una cita inspiradora del propio Sir David Attenborough. Espero que también hayas sacado un poco de inspiración de esta charla y que puedas aplicar algunos de nuestros aprendizajes en tu propio camino de migración. Y, por supuesto, esta cita no se trata necesariamente del mundo natural. También se trata del desarrollo front-end, que también es una gran fuente de emoción. Y lo que también fue una gran fuente de emoción para mí fue dar esta charla y poder compartir nuestra historia. Como dije antes, si quieres comunicarte conmigo, no dudes en contactarme de cualquier manera posible y estaré encantado de hablar contigo. Muchas gracias y espero verte en la próxima conferencia.
React Advanced Conference 2021
Vue.js London 2023
Node Congress 2022
React Summit 2024
Comments