Creando mi primera biblioteca de código abierto Vue 3

Hablemos de Vue 3 y de cómo crear tu primera biblioteca de código abierto. Así que hay algunos objetivos que quiero tener para esta charla hoy. Vamos a hablar de las elecciones de diseño y los requisitos, y voy a hablar de un ejemplo personal de cómo creé una biblioteca de código abierto en Vue 3 en los últimos años. Vamos a hablar de la comunidad y el código abierto y cómo lidiar con eso. Vamos a ver algunas lecciones aprendidas que he tenido a lo largo de todo este proceso, cosas que hubiera hecho de manera diferente y cosas que salieron muy bien. Y luego tendré una conclusión y algunas cosas que puedes tener en cuenta si vas a crear un proyecto de código abierto.

Así que hagamos un pequeño experimento mental antes de seguir adelante. Imaginemos que quieres crear una biblioteca de Vue 3. Digamos que estás en un equipo, tienes algunas utilidades, tienes algo que quieres abrir y poner en el mundo para que cualquiera pueda contribuir. ¿En qué cosas debes pensar al crear esta biblioteca de código abierto? ¿Y qué cosas debes tener en cuenta? Básicamente, pensemos en cómo deberías construirla.

Hay algunas formas de construir aplicaciones modernas de Vue 3 hoy en día. Tenemos Vue CLI, aunque no se recomienda, pero puedes usarlo. Y está Vite. Hay JavaScript o TypeScript. Hay Options API o Composition API. Hay Pina o XState. Y luego está JSX. Una cosa a tener en cuenta es que aunque estés usando Vue 3, que a menudo utiliza estas plantillas, puedes, ya que estás utilizando una biblioteca de código abierto, usar algo como JSX. Porque mucha otra gente conoce JSX si vienes de React u otro framework que lo utiliza, es bastante popular. E incluso Vue.ify lo utiliza en su biblioteca de código abierto. Así que tienes que tomar algunas de estas decisiones. Al final del día, la respuesta correcta no siempre es obvia. No siempre es obvio cuál es lo correcto o lo incorrecto, y tienes que hacer algunos compromisos, y puede que no sea exactamente la respuesta correcta al final del día.

Lo que voy a mostrarles ahora es un proyecto en el que trabajé en los últimos dos años como miembro del equipo de Amplify UI, y les contaré algunas de las decisiones que tomamos y cómo resultaron. ¿Quién soy yo? Soy un desarrollador en AWS que trabaja en las bibliotecas de código abierto de Amplify. Es posible que me hayan visto en línea. Tengo un canal de YouTube llamado ProgramWithEric en eric.video. También he escrito algunas publicaciones en blogs y también soy un defensor del desarrollo, por lo que recientemente he cambiado de roles para ser un DA, lo cual ha sido increíble ya que puedo hablar con muchos desarrolladores y hablar realmente sobre Amplify y todas las herramientas que tiene.

Me gusta comenzar la charla con este cómic de XKCD que habla sobre cómo escribir buen código. En la parte superior, puedes ver que comienza con `comenzar proyecto`, luego `hacer las cosas bien` o `hacerlas rápido`, y luego, si vas rápido, ¿funciona ya? O si haces las cosas bien, ¿escribes buen código? ¿Ya está hecho? Pero en la parte inferior, a menudo sucede que tiras todo tu trabajo y comienzas de nuevo. Tan pronto como creas código en cualquier tipo de proyecto, después de que se supone que has terminado, se convierte en algo que es una aplicación heredada que necesita ser mantenida. Y lo que sucede es que pasa un año, dos años, llegan nuevos equipos, llegan nuevas personas, la tecnología está obsoleta, a menudo se vuelve a escribir. Y eso es algo similar a lo que sucedió con este proyecto del que voy a hablarles.

El proyecto del que quiero hablar en esta charla es lo que describo cariñosamente como el autenticador, un sistema de autenticación. Es un widget, es como un componente que puedes agregar a tu aplicación que te brinda autenticación para que puedas iniciar sesión en una aplicación, puedes crear una cuenta nueva. Pero también tiene autorización, por lo que está respaldado por Cognito para que puedas proteger tus rutas solo para usuarios autorizados. Es solo una cantidad mínima de código de boilerplate que agregas a tu aplicación para agregar un sistema de autenticación y autorización. Y es completamente personalizable, admite todo tipo de cosas como inicio de sesión federado con Google o Amazon, y también admite autenticación de múltiples factores, por lo que fue un proyecto bastante grande para asumir.

Ya teníamos dos versiones anteriores de este Authenticator en uso. Originalmente se escribió, creo, alrededor de 2019, donde se utilizaba una versión muy antigua de Vue 2. Luego se reescribió para usar componentes web y Stencil. Y esta fue nuestra tercera ronda de reescribir esta aplicación, este componente, para que fuera más fácil de usar. Descubrimos que el uso de componentes web y Stencil tenía muchos problemas interesantes, especialmente con los administradores de contraseñas y la forma en que funciona el DOM, y encontramos algunos problemas de personalización. Así que decidimos reescribir este componente web, que en realidad funcionaba no solo para Vue, sino también para React y Angular, y reescribirlo también en las bibliotecas nativas que admiten. Así que reescribimos el Authenticator utilizando Vue 3. Y les mostraré cómo funcionó.

A medida que se desarrollaba este proceso, inicié el equipo, como dije, hace un par de años, y creamos una lista de requisitos que queríamos asegurarnos de cumplir. Teníamos estos requisitos. En primer lugar, la accesibilidad era extremadamente importante, y profundizaremos en eso. También queríamos asegurarnos de tener un tamaño de paquete pequeño. Una cosa que a menudo sucede con los proyectos de código abierto es que los agregas a tu aplicación y luego notas que el tamaño del paquete se duplica o se triplica. Y queríamos asegurarnos de que pudiéramos hacerlo lo más pequeño posible. Además, dado que estábamos reescribiendo el Authenticator de Vue, queríamos asegurarnos de incluir también código para React y Angular y poder reutilizar código.

Así que hablaremos un poco más sobre eso. Utilizamos Yarn workspaces con el monorepo. Y luego utilizamos una forma diferente de compartir código. Y luego queríamos tener algunas mejores prácticas de Vue 3. Vue 3 era extremadamente nuevo cuando comenzamos, y las mejores prácticas comenzaban a ser conocidas, pero no eran tan claras como lo son hoy en día. Y, por supuesto, queríamos que nuestra aplicación fuera probada. Teníamos un par de estrategias de prueba. Como mencioné, la accesibilidad era uno de nuestros principales requisitos. Queríamos asegurarnos de que cumpliéramos con WCAG 2.1 AA. Teníamos varios expertos en accesibilidad en nuestro equipo y en otros equipos que ayudaron a realizar pruebas. Ejecutamos algunas herramientas de accesibilidad en él. Nos aseguramos de que cualquier persona que usara diferentes tipos de lectores de pantalla o diferentes tipos de aplicaciones se asegurara de que nuestro componente, si lo agregaban a la aplicación, cumpliera con ese alto estándar. Y en cuanto al tamaño del paquete, analizamos Vue CLI, pero decidimos ir con Vite. Vue era bastante nuevo hace unos años. Realmente nos gusta Vue y cómo crea su tamaño de paquete y lo pequeños que son los tamaños de paquete. Nos aseguramos de que todo fuera compatible con ESM para toda nuestra aplicación, por supuesto. Y redujimos el número de dependencias. Analizamos cosas como LODASH y Moment.js y algunas de esas otras bibliotecas que a menudo son comunes y que podrías agregar a tu aplicación web, las eliminamos en la medida de lo posible. De esa manera, escribimos todas esas funciones nosotros mismos para no tener esas bibliotecas aumentando el tamaño del paquete en la medida que lo hacen.

Ahora, la estrategia de compartir código que teníamos, puedes ver aquí en la parte superior, utilizamos esta especie de biblioteca de componentes principales de AWS Amplify UI que abarcaba xstate y algunas funciones de utilidad. Hablaremos un poco más sobre xstate, pero ese es nuestro sistema de gestión de estado con el que nos quedamos. Y nuestros paquetes para Amplify UI View, UI React y UI Angular también tenían una dependencia del paquete interno de Amplify UI, para que todos pudieran compartir código. Mientras escribíamos los tres al mismo tiempo, tomamos diferentes piezas de código que encontramos comunes entre los tres y luego las volvimos a incluir en Amplify UI. Por cierto, todo esto es de código abierto. Puedes consultar nuestro repositorio si quieres obtener un poco más de detalles sobre cómo se ve hoy en día. Ha cambiado un poco, pero en su mayoría es la misma forma.

Ahora hablé sobre xstate. Y xstate es una biblioteca de máquina de estados finitos que te permite compartir código en tu aplicación. Realmente nos gustó la idea de las máquinas de estados finitos.

Consideramos Vuex y Pina, que son muy conocidos en el ecosistema de Vue 3, pero pensamos que esta máquina de estados tenía más sentido. Funcionaba, tenía bibliotecas para Vue, React y Angular. Y pudimos compartir esa lógica entre la misma máquina de estados en todas las diferentes implementaciones del Authenticator. También tenía un excelente soporte de paquetes cuando teníamos preguntas o problemas. Recibimos un gran apoyo de, creo, David K. Piano. Y se veía realmente interesante. Así que es un proyecto interesante y una forma interesante de manejarlo.

Si hubiéramos utilizado Pina, tendríamos que averiguar cómo hacer que funcione con Vue, Angular y React, y eso probablemente habría sido mucho más trabajo del que valía la pena, mientras que Xstate simplemente funcionó sin problemas desde el principio.

Ahora, en cuanto a las mejores prácticas de Vue 3, esto no era tan conocido cuando comenzamos, pero definitivamente nos enfocamos completamente en la API de composición. Comenzamos con la API de composición y la función de configuración, si recuerdas eso, pero rápidamente pasamos a la configuración de script, y luego las secuencias de comandos de Chris se configuraron con el lenguaje igual a TS.

Teníamos componentes de archivo único con plantillas. Consideramos la ruta de JSX, pero como solo quería comenzar rápidamente y pensé que sería más fácil, comencé con las plantillas. Utilizamos TypeScript. Activamos el modo estricto. Tenemos el modo estricto activado en nuestra configuración de TS. No teníamos permitido ningún error, por lo que no fue tan alto en TypeScript como probablemente deberíamos haber tenido, pero definitivamente lo mantuvimos en ese nivel.

Realizamos el linting de ES. Realizamos lo esencial de Vue 3. Eso es un nivel cuando agregas el linting con Vue 3. Eso nos dio algunas recomendaciones comunes bastante buenas al crear una aplicación de Vue 3 de cómo deberíamos darle estilo. Nos aseguramos de que si había algún error de linting de ES, evitaría la compilación. Luego, utilizamos muchas cosas que probablemente deberías usar para aplicaciones de Vue. Utilizamos slots, utilizamos Vmodels y utilizamos emits. Si has utilizado la aplicación de React, probablemente hayas visto cómo se pasan las funciones como props. Esto es parte de Vue, ¿por qué no simplemente emitir los datos de vuelta? Utilizamos ese patrón con bastante frecuencia. Queríamos asegurarnos de no crear simplemente una biblioteca de Vue que utilizara los idiomas de React. Queríamos asegurarnos de que fueran separados.

Para las pruebas, teníamos un par de opciones diferentes. Utilizamos Vue test utils con la biblioteca de pruebas. La biblioteca de pruebas realmente promueve la accesibilidad y formas de crear tu aplicación. Consideramos Vue test, pero llegó un poco tarde en nuestro proceso. Y realmente queríamos seguir con Jest, así que nos quedamos con Vue test utils.

Terminamos utilizando pruebas de extremo a extremo con Cypress en toda nuestra aplicación, que fue nuestra principal forma de prueba. Luego utilizamos Cucumber, una biblioteca para el desarrollo basado en comportamiento, y te mostraré cómo se ve. Luego nos enfocamos en GitHub Action. Todas nuestras pruebas se ejecutaron en cada PR. Creamos una serie de acciones para ayudarnos a publicar cada uno de nuestros paquetes. También ejecutamos un Canary. Pensamos que esto era bastante novedoso para el trabajo de código abierto. Ejecutamos un Canary que utiliza Vue, CLI, Vite, V2, V3, y lo mismo para React y Angular. Ejecutamos esta prueba cada 15 minutos, donde crea una aplicación, utiliza nuestra biblioteca, la compila y se asegura de que no haya errores, y luego ejecuta una prueba de extremo a extremo con Cypress para asegurarse de que se pueda iniciar sesión. Ejecutamos esto cada 15 minutos de esa manera y se ejecuta en nuestra última versión. De esta manera, sabemos que si subimos una nueva confirmación a nuestro repositorio que rompa algo, nuestros Canaries se romperán primero. La idea principal era asegurarnos de ser los primeros en saber si rompimos algo en nuestra biblioteca. Y eso ha funcionado muy bien.

Así que aquí tienes un poco de cómo hicimos nuestras pruebas de Cypress Cucumber. Aquí está el escenario: iniciar sesión con credenciales desconocidas. Esta es una forma muy legible para humanos de escribir tus pruebas. Todo esto se traduce a funciones de Cypress que ejecutan las acciones. Cuando escribo mi correo electrónico como desconocido, el correo electrónico y desconocido son como alias que se pasan a una función de Cypress, y luego se ejecuta el código. Y escribo mi contraseña, hago clic en el botón de inicio de sesión, luego veo que el usuario no existe. Tuvimos esto en toda nuestra aplicación y probamos prácticamente todo lo que pudimos utilizando estas pruebas de extremo a extremo de Cypress y Cucumber.

Hablemos de la comunidad. Como somos una herramienta de código abierto, queríamos utilizar obviamente herramientas de código abierto en nuestra aplicación. Utilizamos Yarn workspaces. Tuvimos un debate entre Yarn workspaces y NX, y algunas otras, y Yarn workspaces simplemente ganó, y realmente nos ha encantado con nuestro Monorepo. Y luego utilizamos Next con MDX para nuestra documentación.

Y como sugiere esta charla, definitivamente hicimos de nuestro repositorio de código abierto casi desde el principio. En ningún momento tuvimos un repositorio cerrado o privado, básicamente el primer commit fue un repositorio de código abierto. Dado que había versiones anteriores de este componente de autenticación, creamos un RFC donde pedimos a la community comentarios sobre este nuevo enfoque y la posibilidad de reescribir toda nuestra aplicación, y recibimos algunos buenos comentarios allí. Realizamos una vista previa para desarrolladores, por lo que a medida que avanzábamos, hicimos lanzamientos etiquetados en GitHub para la vista previa de desarrolladores, de modo que si alguien quería echar un vistazo, podía hacerlo, y eso realmente ayudó al principio. Y toda la comunidad de código abierto es increíble al probar estas cosas en nuestra community, sin duda alguna.

Creamos horas de oficina en Discord, por lo que tenemos un canal completo de Amplify en Discord, y en ese canal, semanalmente, tendríamos horas de oficina donde cualquiera puede hacernos preguntas. Brindaríamos actualizaciones sobre nuestro progreso, y en realidad sería en todo el ecosistema de Amplify, porque Amplify no es solo este autenticador, sino también una biblioteca de JavaScript, tiene alojamiento y algunas otras cosas, así que teníamos todo eso abierto.

Luego, recopilamos cada problema de GitHub que teníamos de las versiones anteriores de la biblioteca para ayudarnos a comprender realmente cuáles eran los problemas con las versiones anteriores de las bibliotecas, qué les gustaba a las personas, qué no les gustaba, y eso realmente ayudó a guiar los requisitos que mencioné anteriormente, y también nos aseguramos de saber cuándo habíamos terminado, cuando habíamos solucionado esos problemas.

Esta es una idea interesante que implementamos en nuestros procesos de desarrollo llamada desarrollo impulsado por la documentación. Entonces, ¿qué es el desarrollo impulsado por la documentación? A medida que avanzábamos en nuestra lista de características, documentábamos las características primero, por lo que íbamos y las documentábamos dentro de nuestro sitio de documentación, y luego las implementábamos. Y al mismo tiempo, mientras las implementábamos, agregábamos pruebas unitarias o más a menudo pruebas de extremo a extremo con una aplicación de muestra que se ejecutaba en Cypress que describía la documentación. De esta manera, a medida que escribíamos, sabíamos que la documentación que escribimos funcionaba. Sabíamos que las pruebas que escribimos para esa documentación que escribimos las especificaciones también funcionaban. Realmente, la documentación era una ciudadana de primera clase.

Probamos diferentes plataformas de documentación. Probamos Next, probamos algunas de las plataformas de Vue y decidimos quedarnos con Next, y luego nos aseguramos de que dentro de nuestra plataforma de documentación tuviéramos incrustado nuestro autenticador para que se ejecutara en tiempo real, pero tal vez también simulaba parte del backend para que al menos pudieras probarlo y ejecutarlo. Y eso funcionó bien.

Como usamos Next, terminamos usando el autenticador de React en la documentación para todos los ejemplos, pero descubrimos al final del proceso que el aspecto y la sensación para los clientes entre las versiones de React, Angular y Vue eran idénticos. Eran exactamente iguales, así que no fue un gran problema usar el autenticador de React en nuestra documentación para describir algunas características de Vue porque todos estaban en paridad.

Entonces, esto es lo que es el sitio web de documentación. Miramos la documentación de otros sitios de Amplify y AWS y decidimos ser un poco diferentes. Queríamos enfatizar nuestra accesibilidad, nuestros componentes conectados, porque el autenticador se conecta a nuestros servicios de AWS como Cognito, como mencioné. Así que se nos ocurrió esta idea donde el uso de Amplify es accesible en conjunto, el tema se desempeñará en React y más. Y luego teníamos un pequeño fragmento de código ya que todas nuestras bibliotecas estaban en NPM y luego puedes instalarlo. Y luego, para resaltar lo poco que es la cantidad de código para agregar esto. Aquí tienes un ejemplo de cómo hacer esto en Vue. Simplemente dentro de tu plantilla, agregarías el autenticador y esto produciría todo el autenticador aquí con el inicio de sesión y crear cuenta. Y te daríamos formas de si creaste un sistema backend diferente en Cognito, digamos que agregaste un número de teléfono o un nombre de usuario o tenías ciertas preguntas de registro, se configurarían automáticamente y se tomarían del autenticador para que no tuvieras que configurarlo tú mismo. Así que eso facilitó mucho este proceso. Y luego agregamos otras capacidades y definitivamente muchas cosas diferentes para mover la pestaña de crear cuenta para algunas personas, permitir personalizaciones de la parte superior, los pies de página y encabezados de esto. Así que intentamos agregar muchas personalizaciones diferentes para muchos estilos diferentes y permitir a los clientes modificar el aspecto y la sensación de eso. Todo este proceso tomó alrededor de un año para obtener la aplicación, este autenticador escrito en Vue y lanzarlo como una vista previa para desarrolladores en un par de meses antes de lanzarlo para todos. Así que aquí hay algunas cosas que aprendimos durante todo ese proceso. Como mencioné antes, la paridad entre Vue, React y Angular fue increíble. Al final del día, los tres compartieron mucho código diferente, compartimos algunos estilos y se veían casi idénticos. Y el TypeScript realmente aceleró el desarrollo. Como dije antes, no teníamos súper... Teníamos el modo estricto activado, pero no permitíamos ninguno, así que no era perfecto. Pero solo tener TypeScript fue una bendición y nos alegramos de haberlo hecho. Y ahora incluso tenemos niveles más altos de TypeScript y soporte. Y las pruebas, nos enfocamos mucho en las pruebas de extremo a extremo con Cypress y eso detectó muchos problemas, especialmente durante el desarrollo. Estaríamos trabajando muy de cerca en una nueva característica. Lo subiríamos. Nuestras pruebas de extremo a extremo se ejecutarían, fallarían.

Sabíamos que teníamos un problema y teníamos que solucionarlo. Y creo que encontramos muchos problemas con eso. Y recibimos muchos comentarios positivos de los clientes. Muchas personas que usaban las versiones anteriores de nuestra biblioteca y autenticador pasaron a la nueva, y realmente les gustó. Nos alegró que la revisión nativa y las mejoras en el tamaño del paquete y el aumento de velocidad fueran geniales.

Pero en cada historia, siempre hay cosas que podríamos haber hecho mejor. Teníamos la recomendación de Vue 3, pero deberíamos haber dedicado más tiempo a configurar los niveles de ESLint, establecer niveles personalizados de ESLint, probablemente tener más cobertura en esa área y tal vez haber tenido informes de cobertura y una cantidad mínima de testing antes de que las cosas pasaran. Algo que agregamos más tarde, pero durante el desarrollo no teníamos. Estábamos conformes con el nivel de ESLint, pero definitivamente podríamos haberlo tenido más alto.

Al comienzo del proyecto, estábamos pensando en admitir Vue 2 porque en ese momento muchas personas estaban haciendo la transición, tal vez aún lo estén haciendo hoy en día, de Vue 2 a Vue 3, pero bibliotecas como Vue2Me y algunas otras no eran tan populares como lo son ahora. Ni siquiera creo que existieran. Sería realmente difícil mantener el soporte de Vue 2 en la nueva biblioteca. Aún así, seguimos admitiendo la biblioteca anterior para los usuarios de Vue 2. Lo hacemos hasta el día de hoy, aunque no se está manteniendo, se está manteniendo pero no se le están agregando actualizaciones, pero eso es algo que podríamos haber hecho de manera diferente. Más JSX, así que descubrí mientras trabajaba en el proyecto que hay muchas personas en mi equipo que son expertas en JSX. Esto podría haber sido algo en lo que podríamos haber agregado más y lo estamos explorando a medida que agregamos actualizaciones, si queremos reescribir algunas de nuestras plantillas en JSX, porque ha mejorado mucho. Y una biblioteca de código abierto, no debería importar. Obviamente, nuestros usuarios finales seguirán usando esto en las plantillas. No afectará eso en absoluto. Es solo la forma en que se hace, supongo. Teníamos muchos slots dentro de slots. Teníamos un sistema de anidación muy complicado en el que la idea era que se pudiera anular cualquier función desde un componente profundamente anidado. Mirando hacia atrás en ese código, definitivamente podría haber sido más simple. Tal vez deberíamos haber utilizado Provide e Inject. Tal vez deberíamos haberlo utilizado en algún tipo de sistema de gestión de estado. Creo que eso podría mejorarse. A medida que avanzamos, hemos mejorado mucho eso. Sobredimensionamos las pruebas de extremo a extremo. Las pruebas de extremo a extremo son increíbles porque es casi como si el usuario estuviera haciendo clic en diferentes partes de la aplicación, escribiendo cosas, eres muy minucioso en tus pruebas. La desventaja es que es muy lento y es difícil iterar rápidamente. No hicimos tantas pruebas unitarias como podríamos haber hecho. Creo que deberíamos haber tenido un mejor equilibrio entre las pruebas unitarias y las pruebas de extremo a extremo. Creo que eso habría cubierto más. En este momento, tenemos una cantidad mínima de cobertura de pruebas unitarias que ahora requerimos en cada función. Así que eso se ha corregido, pero durante ese proceso, probablemente deberíamos haber hecho más pruebas unitarias. Este es un problema en el que todavía estamos trabajando hoy en día, todavía estamos tratando de mejorar, cómo hacer que los colaboradores externos ingresen a su biblioteca, sean parte de la comunidad, comenten en RFC e informen problemas, puedan resolver problemas que la comunidad tiene, tal vez trabajar en características. Eso es algo en lo que todavía estamos trabajando. Entonces, si vas a nuestra Biblioteca de Componentes de Amplify UI y miras nuestra lista de problemas, hay muchos allí. No muchos, pero definitivamente hay algunos en los que la comunidad puede trabajar, pero tratar de hacer que la comunidad trabaje en ello, hemos intentado agregar etiquetas, pero es difícil.

Además, tenemos una hoja de ruta de cosas en las que estamos trabajando para el próximo año. Y eso es algo que el público no tiene toda la información, por lo que es difícil para alguien implementar una función que vamos a implementar en tres meses. Así que todavía estamos tratando de mejorar eso. Eso es algo que estamos aprendiendo.

Entonces hablemos un poco de cómo fue. Hemos analizado todo este proceso a lo largo de dos años, qué salió bien, qué no, pero ¿en qué terminamos? Bueno, una buena indicación de cómo está funcionando cualquier proyecto de código abierto más allá de mirar los problemas, los comentarios y las menciones en Twitter es simplemente mirar las descargas de npm. Este es un gráfico de las tendencias de npm. Y así lanzamos la biblioteca de vistas AWS Amplify/UI. Estuvo rondando, probablemente entre cinco y diez mil durante bastante tiempo. Pero a medida que comenzamos a poner más esfuerzo en ello y creamos esta nueva biblioteca, puedes ver que casi se ha duplicado en la cantidad de descargas en un año, lo cual ha sido realmente increíble. Y estas son descargas semanales. Pasamos de 10,000 descargas semanales a 20,000 descargas semanales, y ha seguido aumentando desde entonces. Y varía dependiendo de la temporada y el momento, pero estamos realmente contentos de que la gente lo esté utilizando. Y este mismo tipo de gráfico se puede ver en UiReact y UiAngular. React definitivamente ha tenido más descargas, pero también ha aumentado aproximadamente la misma cantidad.

Si necesitas más información, puedes enviarme un tweet a EricCH. Si tienes un momento, no dudes en consultar el repositorio AWS Amplify U. Agradezco a todos por escuchar. Estaré disponible. Gracias.