Blitz.js - El marco de trabajo React Fullstack

Estuve construyendo aplicaciones de React de pila completa durante algunos años. Y felizmente soporté la complejidad y la lucha requerida para hacerlo. Y lo hice porque amaba construir interfaces de usuario con React más que cualquier otra forma. Pero la luna de miel terminó. Y me frustré cada vez más con REST, con las API de GraphQL, con el árbol de estado de Momex y una serie de otros servicios y bibliotecas de API, gestionando múltiples servidores, gestionando múltiples implementaciones, etc. Cualquier cosa que se interpusiera en mi camino para construir características agotaba lentamente mi moral.

Realmente quería volver a amar el desarrollo web de pila completa. Quería ser extremadamente productivo nuevamente en la construcción de aplicaciones de pila completa. Quería centrarme en construir características en lugar de mover datos por todo el universo. Así que decidí que ya era suficiente y me propuse construir la mejor experiencia de desarrollo posible para aplicaciones de React de pila completa. Bueno, había dos cosas fundamentales que debía tener en su lugar para lograr la experiencia de desarrollo que quería. En primer lugar, debía ser monolítico. Y un monolito significa que solo hay una cosa. Todo está junto en una sola cosa, por lo que solo hay una cosa para desarrollar, solo hay una cosa para implementar, solo hay una cosa para pensar en toda su arquitectura. Y un monolito es realmente increíble. Y en mi experiencia con Ruby on Rails, llegué a apreciar realmente los beneficios de un monolito. En segundo lugar, no hay API. La capa de API en las aplicaciones de React es la mayor fuente de complejidad, dolor de cabeza, angustia, agujeros en la pared. Oh, vaya Brandon, eso es demasiado, te ralentiza más de lo que piensas. Y sabía que tenía que deshacerme de eso de alguna manera. Vale Brandon, eso suena genial, pero ¿cómo lo vamos a hacer? ¿Significa que tenemos que volver a 2004 y hacer representación del lado del servidor? Así lo pensé. Y estaba dispuesto a aceptarlo. Porque quería esta experiencia de desarrollo, sin la API, tanto que estaba dispuesto a seguir ese camino. De hecho, cuando anuncié por primera vez que estaba trabajando en Blitz, el prototipo inicial era de representación del lado del servidor. Pero los primeros colaboradores de Blitz y yo estábamos tratando de descubrir cómo sería realmente la arquitectura de Blitz. Exploramos todo tipo de cosas, modelo-vista-controlador, básicamente todo bajo el sol. Un día, estaba tumbado en una hamaca en Tailandia, pensando en esto, y me pregunté cómo sería esto si fuera fácil. Así que pensé en eso por un momento y me di cuenta de que si fuera fácil, podrías escribir funciones que se ejecuten en el servidor y luego importarlas directamente en tus componentes de React y usarlas directamente. Así que podrías usarlas sin hacer llamadas fetch o puntos finales de API o HTTP o algo así.

Simplemente funcionaría. Y pensé, wow, eso es bastante impresionante. Esto podría ser un cambio de juego. Y resultó serlo.

Bien. Ahora conoces el factor más importante que define lo que es Blitz, así que hablemos de los otros dos. Mencioné que estaba frustrado con el desarrolloweb de pila completa en realidad, pero durante todo ese tiempo hubo una cosa que constantemente se destacaba entre el desorden, y eso era Next.js. Next es un marco maravilloso. Es rápido, flexible y eficiente y proporciona una buena experiencia para los desarrolladores. Y fue tan claro que era algo perfecto para construir encima y agregar todas las otras cosas que necesitas para el desarrolloweb de pila completa.

Bien, ahora necesitamos una forma de comunicarnos con la base de datos. Y en febrero, cuando comencé con Blitz, Prisma 2 acababa de salir en beta, y era obvio que esta sería la forma moderna de acceder a las bases de datos. Y si no conoces Prisma 2, es genial porque tienes un esquema realmente agradable que puedes definir y tener migraciones declarativas a partir de ese esquema. Generas un cliente de TypeScript a partir de ese esquema, por lo que tienes acceso a la base de datos completamente tipado. Y luego en Blitz, esos tipos pueden fluir hasta tu frontend. Por lo tanto, todo está completamente tipado de principio a fin.

Muy bien, esos son los tres factores clave de lo que es Blitz. Hablemos de las siete características y principios fundamentales que definen todo lo demás que hacemos. Entonces, pila completa y monolítica, ya he mencionado eso. Quiero mencionar que un monolito moderno escala mucho mejor que, por ejemplo, Ruby on Rails. Y eso se debe a que puedes implementar Blitz en un entorno serverless. No solo en un servidor, puedes hacer ambas cosas. Pero si lo implementas serverless, todos tus puntos finales del servidor pueden escalar de forma independiente como funciones serverless. Por lo tanto, el tema de la escalabilidad con un monolito simplemente desaparece. Eso es realmente impresionante. En segundo lugar, no se requiere una API. En tercer lugar, convención sobre configuración. En cuarto lugar, opiniones flexibles en comparación con opiniones fuertes que son difíciles de contradecir. En quinto lugar, fácil de comenzar, fácil de escalar. En sexto lugar, estabilidad.

Y en séptimo lugar, community sobre código. Bien, hablemos un poco de esta capa de API y veamos cómo lo hacemos y cómo funciona. Abstraemos la API en un paso de compilación. Entonces, mientras desarrollas tu aplicación, como mencioné, no haces nada relacionado con la API, simplemente importas las funciones del servidor en tu frontend y luego en tiempo de compilación las reemplazamos por una API HTTP. Y así obtienes renderizado en el lado del cliente, pero sin ninguna complicación de la API.

Y cómo haces eso en una aplicación Blitz es lo que llamamos consultas y mutaciones. Ahora esto no tiene nada que ver con GraphQL, simplemente usamos la misma nomenclatura y son funciones asincrónicas JavaScript simples que siempre se ejecutan en el servidor. Si estás familiarizado con Ruby y Rails, o Laravel, el concepto de controlador, básicamente se reemplaza por consultas y mutaciones. Por supuesto, siempre puedes agregar una API a una aplicación Blitz porque no tenemos ninguna restricción que te impongamos. Así que somos 100% compatibles con Next.js. De hecho, tenemos menos restricciones que Next.js. Así que no tienes que preocuparte de que Blitz se interponga en tu camino. Muy bien, veamos aquí un diagrama de arquitectura para darte una idea aproximada de cómo encaja todo esto. A lo largo de la parte superior está el código del lado del cliente, a lo largo de la parte inferior está el código del lado del servidor. Y las cajas moradas son páginas, páginas de React. Y puedes ver que en una sola aplicación puedes tener una página renderizada en el lado del servidor y una página renderizada en el lado del cliente una al lado de la otra. Y pueden usar el mismo código del servidor. Las cajas verdes en la parte inferior son una consulta y una mutación. Y ambas páginas usan la misma consulta. Y luego, en el momento de la compilación, esta capa intermedia se inserta automáticamente para ti, que es una API JSON HTTP. Por lo tanto, todas tus consultas y mutaciones están expuestas en una URL única. Y puedes usarla directamente para aplicaciones móviles o terceros o cualquier otra cosa.

Bien. Hablemos de la convención sobre la configuración. Esto significa que, de forma predeterminada, las cosas simplemente funcionan. Y no significa que no haya configuración. Simplemente significa que la configuración es opcional. Por lo tanto, la mayoría de las cosas aburridas están completamente hechas por ti desde el principio. Y especialmente puedes ver mucho de esto como un principio cuando generas una nueva aplicación. Porque tiene muchas cosas configuradas para ti, básicamente todas las cosas que configurarías en la primera semana aproximadamente de un nuevo proyecto.

Bien, vamos a ver algo de código. Muy bien, entonces esta es una mutación de registro que siempre se ejecuta en el servidor. Y básicamente esto es lo que obtendrás en una nueva aplicación de forma predeterminada. Esto se generará para ti. Entonces, puedes ver que exportamos una función asincrónica predeterminada. Y el primer argumento de eso es el argumento de la mutación. Y el segundo es un parámetro de contexto. Y este parámetro de contexto es proporcionado por el middleware y Blitz. Y por defecto tienes un middleware configurado, que es el middleware de sesión. Y eso es una sesión integrada de gestión de Blitz. Ok, y dentro de esta mutación, lo primero que vamos a hacer es validar la entrada. Y usamos una biblioteca llamada Zod que es realmente increíble tanto para runtime validation como para los tipos de TypeScript. Así que tienes la garantía de que después de esta línea, el correo electrónico y la contraseña son cadenas, y la contraseña tiene una longitud mínima. Ok, y luego vamos a cifrar la contraseña y luego vamos a crear un usuario en la database. Y este objeto db es proporcionado por Prisma 2. Y así puedes ver lo fácil que es crear un usuario. Así que correo electrónico, una contraseña, y obtienes ese usuario de vuelta. Y luego, en segundo lugar, lo último que hacemos antes de devolver es crear una nueva sesión, que es cómo inicias sesión. Y puedes establecer el ID de usuario, roles, cualquier otra cosa que necesites allí para usar en el frontend. Ok, bastante simple. Ahora, ¿cómo lo usamos? Bueno, importas esta función directamente en tu componente. Y así aquí está el formulario de registro. Y puedes ver que importamos, está en la 5ª línea creo, importamos esa función que acabamos de ver. Y la pasamos al gancho de uso de mutación dentro del componente. Y luego simplemente podemos usar esa mutación dentro del gancho de envío propio. Y simplemente lo llamas esperar como una función regular allí. Y simplemente funciona para ti. Muy elegante. Muy bien, veamos otro. Esta es una consulta de proyecto git.

Entonces, puedes ver nuevamente que obtenemos algunas entradas y luego el parámetro de contexto. Y lo primero que hacemos en este caso es llamar a session.authorized. Y esto se asegurará de que el usuario haya iniciado sesión. Si no lo está, lanzará un error. Y ese error se propagará hasta el frontend y mostrará un formulario de inicio de sesión si no han iniciado sesión o lo mostrará en una página no autorizada si no cumplen con la regla requerida. Y, por supuesto, puedes personalizarlo como quieras. Pero esa es la configuración predeterminada. Entonces encontramos el proyecto y si no lo encontramos, no obtenemos el proyecto y lanzamos un error de no encontrado y nuevamente eso se propaga al frontend y muestra una página 404.

Bien, usemos esto. Simplemente importamos esta función en tu componente. Y dentro de este componente de proyecto, lo primero que hacemos es obtener el parámetro de la ruta. Entonces esto es project ideas. Un parámetro dinámico que obtienes de la URL y luego tenemos un gancho useQuery al que le pasas esa función de consulta que acabamos de ver, se la pasas a useQuery y luego el segundo parámetro es el argumento donde id es igual al id de esta ruta y luego obtienes eso y simplemente lo renderizas. Ahora, una cosa a tener en cuenta aquí es que tenemos el modo concurrente habilitado en Blitz de forma predeterminada, por lo que estás usando suspense, que es realmente increíble. Entonces puedes ver en este componente que no tenemos todo este baile de if else de si está cargando muestra la carga, si hay un error muestra el error, si hay algo más muestra algo, lo cual es muy simple y realmente genial. Y luego, en el componente de página hacia la mitad inferior de la pantalla, puedes ver que tenemos el componente suspense y el fallback para el error, por lo que es una API realmente agradable. UseQuery se basa en react-query y react-query proporciona muchas cosas increíbles que obtienes de forma predeterminada aquí, como el almacenamiento en caché de todos tus datos del servidor, la validación, la actualización, todas estas cosas realmente poderosas y simplemente las obtienes de forma predeterminada.

De acuerdo, ¿cómo empiezas con Blitz? Bueno, es bastante sencillo, solo hay dos comandos y lo primero es instalar Blitz globalmente como una CLI y luego, en segundo lugar, ejecutar Blitz new y pasarle el nombre de tu aplicación y eso es todo. Y simplemente generará tu aplicación, instalará tus dependencias, etc., y luego, como mencioné, puedes registrarte e iniciar sesión de inmediato como usuario y es increíble.

Bien, hablemos de la comunidad en lugar del código, este es uno de nuestros principios fundamentales. Las personas son mucho más importantes que cualquier otra cosa y estos son principios que valoramos mucho en la comunidad de Blitz, pero también son principios que nosotros, como comunidad tecnológica en general, realmente abrazamos y vivimos. En segundo lugar, tratamos a cada persona con dignidad y valor, independientemente de quiénes sean, cuáles sean sus creencias, cada persona merece dignidad y valor. Todos estamos juntos en esto, todos queremos ser productivos, todos queremos divertirnos en nuestros trabajos y todos somos más similares de lo que somos diferentes, por lo que podemos y debemos resolver problemas juntos. Tenemos una página completa en nuestra documentación vinculada aquí que detalla cómo opera la comunidad de Blitz, repasaremos prácticamente todo para que puedas tener una buena idea si quieres involucrarte en la comunidad de Blitz o no, si quieres ver cómo funcionan las cosas, ese es un buen lugar para hacerlo.

De acuerdo, ahora hablemos de cómo puedes contribuir a Blitz. Necesitamos tu ayuda, nos encanta toda la ayuda que podamos obtener, tenemos muchas características en nuestro repositorio de GitHub listas para trabajar, pero simplemente están esperando a que alguien trabaje en ellas. Estoy trabajando principalmente a tiempo completo en Blitz y luego haciendo consultoría en el lado. Hasta ahora, estoy contribuyendo con la mayor parte, pero nos encantaría que cualquier otra persona ayudara en su tiempo libre tanto como pueda. Apreciamos cualquier tipo de contribución, ya sea código, documentación, mejorar la documentación, tutoriales, videos, publicaciones de blog, cualquier cosa que se te ocurra. En segundo lugar, se agradecen las donaciones y patrocinios, mi objetivo es trabajar a tiempo completo en Blitz sin tener que hacer consultoría en el lado y luego, además de eso, me encantaría pagar a otras personas para que trabajen a tiempo completo en Blitz también. Me encantaría cualquier tipo de donación o patrocinio que puedas brindarnos a través de GitHub. Hay un botón en nuestro repositorio de GitHub.

Y luego, en segundo lugar, el mejor lugar para comenzar aquí es esta documentation de blitzjs.com, que está enlazada aquí. Así concluye el final de mi presentación. blitzjs.com es el mejor lugar para ir a comenzar allí, puedes seguirme en Twitter como Flybear y también a Blitzjs en Twitter. Me encantaría responder tus preguntas ahora y en cualquier momento más tarde en Twitter, cualquier cosa, solo contáctame, estaré encantado de ayudar a responder preguntas y me encantaría que probaras Blitz y me cuentes cómo te va. Muchas gracias.

Increíble, bienvenido. Muchas gracias por tu charla. Voy a pasar directamente a algunas preguntas. En primer lugar, felicidades por Blitz, parece que va muy bien. ¿Cuándo será la versión 1.0? Así que actualmente lo estamos discutiendo. Actualmente estamos en estado alpha, pero estamos discutiendo cambiar al estado beta probablemente en una o dos semanas. Así que nos estamos acercando. Ahora que básicamente estamos casi en estado beta, nos enfocamos en pulir los detalles, solucionar errores, agregar más pruebas y todas esas cosas para llegar a la versión 1.0. Así que no hay cambios importantes planeados. Con suerte, hacia finales de este año o principios del próximo año, seremos 1.0, veremos cómo se desarrolla. Hablaste un poco sobre la comunidad, pero ¿podrías contarnos un poco más sobre quiénes están involucrados y cómo lo estás gestionando? Claro. Además de mí, hay otros dos miembros del equipo central, Rudy y Dylan. Y luego creo que ahora tenemos alrededor de tres mantenedores de nivel dos, y los mantenedores de nivel dos tienen la responsabilidad de una parte específica del código y ayudan a gestionar la revisión de las solicitudes de extracción y su fusión. Luego hay alrededor de ocho mantenedores de nivel uno que nos ayudan en la comunidad, respondiendo preguntas, etc. Y luego hay una gran cantidad de otros colaboradores. Creo que ahora somos más de 120 personas en total que han contribuido de alguna manera a Blitz, ya sea con código, documentación, etc. Así que es una gran comunidad. Todos nos divertimos mucho y cualquier persona es bienvenida para venir y ayudar a contribuir.

Esto es realmente increíble. Estás dedicando tiempo completo a esto, creo que mencionaste. ¿Cómo es la vida como mantenedor en el código abierto? Claro. Actualmente, dedico aproximadamente 30 horas por semana en promedio a Blitz y luego otras 20 o 25 por semana haciendo consultoría para mantenerme. Así que un día típico se ve así. Me despierto, reviso Blitz Slack y respondo preguntas, reviso algunas cosas y luego hago trabajo de consultoría para pasar la primera parte del día, y cuando me aburro de eso, cambio y hago cosas de Blitz durante el resto de la tarde.

Eso es increíble. Algunos de la audiencia quieren saber si tú o tu comunidad tienen buenos recursos para alguien que tal vez no haya contribuido antes al código abierto y quiera comenzar. Tenemos una página de Cómo Contribuir en nuestra documentación y tratamos de explicarlo de manera muy clara, como primer paso, tenemos un enlace al video de Kent C. Dodd en egghead sobre cómo comenzar con el código abierto. Así que ese es el mejor lugar para comenzar y luego te guiamos sobre cómo clonar el repositorio de Blitz y qué tipo de cosas puedes trabajar. Tenemos una serie de problemas etiquetados como listos para trabajar y también los etiquetamos como buen primer problema y buen segundo problema, y muchas veces los buenos primeros problemas son realmente fáciles, como cambiar una palabra o algo muy simple, muchas veces se solucionan en una hora desde que los publicamos, así que solo tienes que estar atento al repositorio. Eso es genial, apuesto a que algunos otros mantenedores están un poco celosos en este momento. ¿Cómo te involucraste en Blitz? ¿Tuviste una mala experiencia con una API y dijiste que nunca más querías hacer esto? Así que hablé un poco de eso en la charla, pero comencé a desarrollar aplicaciones web con Ruby on Rails en 2014, creo que fue cuando comencé a aprender programación web porque antes hacía C y C++. Aprendí Ruby on Rails y fue bastante fácil hacer cosas de pila completa, luego pasé a React y me encantó, pero luego tuvimos toda esa capa de API que lo hace mucho más complejo que Ruby on Rails, y finalmente decidí que era suficiente y necesitábamos tener ese mismo tipo de experiencia fácil y simple de pila completa que obtienes con Ruby on Rails o Laravel o Django y llevarlo a React. ¿Extrañaste Ruby on Rails? Sí y no. Hay muchas cosas que me gustaban de Ruby on Rails, especialmente cómo no hay una API allí, pero también hay muchas cosas que no me gustaban. Me gusta JavaScript y TypeScript mucho más que Ruby, así que mi objetivo es tomar todo lo bueno de Rails en mi opinión y dejar fuera todo lo malo. Creo que lo hemos logrado bastante bien. La semana pasada, uno de los desarrolladores de Blitz había estado usando Blitz durante un par de meses y dijo que había estado desarrollando aplicaciones de Ruby on Rails profesionalmente durante 10 años y ahora, después de solo unos meses con Blitz, ya es 10 veces más productivo que nunca con Ruby on Rails. Así que eso es algo sorprendente. Eso es genial, sí. Genial. Bueno, tenemos una pregunta de Oakley en el chat, ¿es Blitz.js adecuado si tienes una API compartida que es consumida por múltiples plataformas, como iOS, Android, Nativo y JavaScript? Sí, así que supongo que tienes una API existente a la que quieres conectarte y absolutamente puedes hacer eso con Blitz. Puedes hacerlo como lo harías normalmente con Next.js, por ejemplo, simplemente conectándote a la API desde el cliente, o la otra forma de hacerlo es usar consultas y mutaciones de Blitz y comunicarte con la API desde el servidor y luego usar la capa de datos de la API de Blitz para gestionarlo, y al hacerlo, puedes usar la gestión de sesiones de Blitz, que es muy fácil e integrada en lugar de tener tu propia autenticación de alguna manera. Así que depende totalmente de ti, totalmente flexible. Eso es bueno. La flexibilidad es importante. No sé si te hacen esta pregunta con frecuencia, pero es un clásico. ¿Hay algo para lo que Blitz no sea adecuado y cuándo no lo usarías? Nuestra especie de lema o objetivo es ser el framework para el 99% de nosotros que trabajamos en empresas con menos de 100 empleados. Así que Blitz probablemente no sea adecuado para construir algo tan masivo como el núcleo de Facebook. Simplemente es demasiado complejo para algo tan grande, pero puedes comenzar la próxima Facebook con Blitz y definitivamente crecerá contigo y terminarás necesitando crear otros servicios alrededor.

Eso. Pero es realmente genial para prototipar en este momento y también tenemos muchas personas que están construyendo aplicaciones SaaS de producción. Entonces, cualquier tipo de aplicación en la que necesites tener un inicio de sesión, una base de datos y te conectes a ella, es realmente genial para eso. Y especialmente para creadores, emprendedores independientes y nuevas startups, es realmente genial. Genial. ¿Tienes, tal vez no oficialmente, pero en tu cabeza, una buena visión futura para Blitz? ¿Cómo se vería una versión 2.0 o una 5? Buena pregunta. Lo más importante, y realmente lo principal en lo que tengo una visión, es tener la misma experiencia Zero API que tenemos ahora con la web y llevar eso a dispositivos móviles, por ejemplo, con React Native. Hoy en día puedes usar Blitz con aplicaciones móviles. Puedes conectarte a los puntos finales de la API generada y usarla normalmente. Tenemos algunas personas que están trabajando en eso. No tienes esa experiencia Zero API. Sigues haciendo las llamadas o lo que necesites hacer desde el móvil. Lo primero que podemos hacer para eso es generar un cliente de API y eso es relativamente sencillo. Podemos hacerlo para varios lenguajes diferentes, por lo que facilita tener un cliente con tipos y comunicarse fácilmente con el backend de Blitz. Luego, incluso más allá de eso, quiero tener un soporte donde tengas un monorepo en el que tengas tu aplicación web Blitz normal y también una aplicación React Native en el mismo repositorio, y luego puedes importar tus consultas y mutaciones de Blitz directamente en tu código React Native y luego lo cambiaríamos en tiempo de compilación para que sea el mismo tipo de cliente de API que hacemos con la web. Así que queremos llevar eso a dispositivos móviles. Estoy bastante seguro de que eso es posible, podemos hacerlo de alguna manera, pero eso definitivamente está un poco más adelante en el roadmap, pero eso sería realmente genial para que tengas esta aplicación multiplataforma completa, aplicación web, aplicación móvil, sin lidiar con REST o GraphQL o cualquier otra cosa. Blitz en todas partes. Eso es el espíritu, ¿verdad? Metin del chat quiere saber, ¿alguna vez has considerado agregar algunas de estas características a Next.js, ya que también es de código abierto? El equipo de Next.js es bastante claro al respecto, están resolviendo los problemas, el alcance en el que están ahora, quieren mantenerlo, donde es relativamente mínimo y están resolviendo problemas que son prácticamente universales, como cosas de nivel inferior, trabajando en RFC para internacionalización, RFC para un componente de optimización de imágenes. Entonces, estas son cosas fundamentales de nivel inferior, pero donde Blitz es un poco más opinativo. Tenemos la capa de base de datos, la capa de datos de pila completa. Entonces, no quieren ir por ese camino de opiniones. Creo que funciona bien porque hay muchas personas que quieren ese nivel inferior y quieren traer todas sus propias opiniones y crear su pila perfecta al final. Pero también hay otras personas para las que Blitz es bueno, que no quieren pasar una o dos semanas eligiendo bibliotecas y configurando cosas y conectándolas. Solo quieren construir algo. Bastante justo. Dennis quiere saber, estoy un poco curioso acerca de cómo se manejarían las actualizaciones de Blitz en el proyecto que utiliza Blitz. Como si en algún momento se va a cambiar alguna biblioteca subyacente. Ahora mismo, Blitz, hay una dependencia, actualizas Blitz y listo.

Ahora puedes realizar algunos cambios de edición, que ocasionalmente hay. Solo tienes que consultar las notas de lanzamiento y realizar ese cambio. Luego, después de llegar a la versión 1.0, vamos a implementar un ciclo de lanzamiento realmente estable y predecible inspirado en Ember. Como lo hace Ember, cada seis semanas hay un nuevo lanzamiento estable. Luego también hay un lanzamiento LTS que se lanza cada seis meses. El próximo lanzamiento está en beta durante seis semanas. Eso es estable y es poco probable que tenga errores en la versión final. Y los cambios que rompen la compatibilidad se manejan correctamente con deprecaciones. Planeamos hacer eso.

También tenemos algo llamado Recetas de Blitz, que creo que no mencioné en mi charla. Es un comando para instalar cualquier tipo de código de terceros. Puedes hacer blitz install TEOWIN, blitz install Chakra, blitz install Emotion. Tenemos algunas de esas, todavía las estamos desarrollando. Eso es otra cosa realmente increíble. A donde iba con eso es que eventualmente podríamos tener blitz install blitz. Y actualizaría blitz automáticamente por ti. Eso es realmente genial. Se nos acabó el tiempo, Brandon, pero muchas gracias por pasar por aquí. Todos pueden encontrar a Brandon en el Discourse o más tarde en las salas. ¡Gracias! ¡Gracias! www.microsoft.com www.microsoft.com www.microsoft.com Microsoft www.microsoft.com Microsoft www.microsoft.com www.microsoft.com www.microsoft.com www.microsoft.com www.microsoft.com www.microsoft.com www.microsoft.com www.microsoft.com