Un vistazo al futuro del desarrollo full-stack con Blitz.js

Hola, hoy voy a hablar sobre el futuro del desarrollo web full-stack con Blitz.js. Les presentaré lo que actualmente es Blitz y les daré un vistazo de lo que será en el futuro. Mi nombre es Aleksandra y actualmente estoy manteniendo Blitz y anteriormente dirigí un equipo de consola de Hasura. Puedes encontrarme en GitHub y Twitter y también puedes visitar mi sitio web personal.

La agenda de hoy es hablar sobre el pasado, el estado actual y el futuro de Blitz. Pasaremos por los conceptos y características principales, y luego explicaré cuáles son nuestros planes y en qué estamos trabajando actualmente. Algunos de ustedes ya habrán oído hablar de Blitz o tal vez incluso lo hayan usado en sus proyectos. Para aquellos que no lo han hecho, Blitz es un framework full-stack de React. Fue enormemente inspirado por Ruby on Rails y construido con la motivación de empoderar a los desarrolladores y brindarles la mejor experiencia posible para construir aplicaciones full-stack y de React. Blitz está construido sobre Next.js. Next es un framework principalmente enfocado en el frontend, donde Blitz agrega todas las características y funcionalidades faltantes que lo convierten en un framework full-stack. Incluye acceso directo a la base de datos, middlewares, autenticación con autorización. Para el acceso a la base de datos, Blitz utiliza Prisma por defecto. Es un framework con todo incluido, lo que significa que todas las cosas aburridas como Slint, Prettier, Husky, TypeScript, Jest ya están configuradas para ti. Puedes ir directamente a escribir la lógica de negocio y enviar tus productos.

Uno de los conceptos principales es que Blitz es monolítico. Significa que puedes razonar sobre tu aplicación como una sola entidad. Solo hay una cosa de la que desarrollar, desplegar y pensar. Ahora, hablemos de algunas de las características principales. La más significativa es la capa de cero API. Si estás usando React, requiere que tengas una API REST o GraphQL para conectarte a la base de datos o realizar alguna lógica de negocio, que se supone debe realizarse en el servidor. Necesitas una API, incluso si no va a ser utilizada por terceros, aparte de tu propia aplicación. A veces también es una fuente de complejidad y a veces podría evitarse. Blitz te permite ejecutar código del servidor directamente desde tu frontend. ¿Cómo sucede esto? Entonces, Blitz abstrae la API en un paso de construcción. Puedes usar una función de servidor en tu frontend, y Blitz intercambiará la importación con una llamada HTTP en el momento de la construcción. Las funciones del servidor se llaman resolutores de Blitz, y tenemos consultas y mutaciones. Sin embargo, son solo funciones de JavaScript simples, que siempre se ejecutarán solo en el servidor. Además, aún puedes agregar tu propia API si es necesario, y Blitz no se interpondrá en tu camino. Echemos un vistazo al diagrama de arquitectura.

En la parte superior, tenemos el código del cliente y hay código del servidor en la parte inferior. En particular, tenemos una consulta y una mutación en la parte inferior. En tu aplicación, puedes tener una página renderizada del lado del servidor y una página renderizada del lado del cliente una al lado de la otra. Con Blitz, pueden usar el mismo código del servidor. En el tiempo de construcción, la capa intermedia se genera e inserta para ti. La capa intermedia es esta API JSON autogenerada en el diagrama. Cada consulta y mutación se expone en una URL única, lo que significa que también puedes llamar a esas URLs directamente, por ejemplo, desde otra aplicación.

Aquí tenemos una consulta basada en un ejemplo, se llama getProject, y echemos un vistazo a lo que sucede aquí. Entonces usamos Zote para definir la forma de los parámetros de la consulta. Luego analizamos la entrada para asegurarnos de que es lo que queremos. Más tarde, hay una llamada a la base de datos, usamos Prisma aquí, y con esta llamada, estamos tratando de encontrar el proyecto con un ID dado. Al final, la consulta devuelve el proyecto que estábamos buscando en la base de datos. En un componente, lo pasamos a una función useQuery importada de Blitz. Está construida sobre React Query, que es una gran biblioteca que proporciona almacenamiento en caché, sondeo, gran experiencia para el desarrollador, y muchas, muchas más características.

Ahora echemos un vistazo al ejemplo de mutación. No es muy diferente de la función anterior. También definimos la forma de la entrada, la analizamos, nos conectamos a la base de datos para crear un nuevo objeto, y al final, devolvemos el proyecto recién creado. En un componente de React, pasamos esta función a un useMutation, y luego la usamos al enviar el formulario. Otra gran cosa sobre Blitz es que tiene autenticación y autorización listas para usar. Después de crear una nueva aplicación, puedes registrarte e iniciar sesión instantáneamente. Todo el código necesario para crear nuevas cuentas para iniciar y cerrar sesión ya está generado para ti. También hay un adaptador de Passport.js, que te permite agregar un inicio de sesión de terceros. Aquí podemos ver la mutación de registro proporcionada para ti en los proyectos de Blitz. Este código ya está allí después de que creas una nueva aplicación de Blitz. Entonces, ¿qué tenemos aquí? Ciframos la contraseña con una utilidad de contraseña segura importada de Blitz. Luego creamos un nuevo usuario en la base de datos, pasamos los valores de la mutación, y pasamos la contraseña cifrada. Como siguiente paso, creamos una nueva sesión autenticada. El objeto ctx es el segundo argumento de los resolutores de Blitz y es proporcionado por el middleware de sesión y el middleware de sesión está configurado para ti por defecto en tus aplicaciones. En nuestras consultas y mutaciones, también necesitamos poder restringir el acceso al código del servidor. Para eso, podemos usar, por ejemplo, este es uno de los métodos, podemos usar la función authorize.

Entonces, si el usuario no está autenticado, o si no está autorizado para acceder a un recurso, lanzará un error. Blitz también viene con andamiaje de código. Puedes usar la línea de comandos de Blitz para generar modelos, resolvers y páginas. Por ejemplo, el comando Blitz generate all project creará páginas para listar, agregar y editar nuevos proyectos. También creará un nuevo componente de formulario para crear nuevos proyectos. Y finalmente, generará todas las consultas y mutaciones necesarias.

Luego tenemos recetas, que fueron mayormente inspiradas por Gatsby, y nos proporcionan una manera fácil de extender nuestras aplicaciones. Tenemos un montón de recetas en Blitz, y permiten, por ejemplo, agregar bibliotecas de UI, configuración de despliegue, herramientas de registro, y algunas cosas más. Así que otra cosa genial que Blitz introdujo son las rutas seguras por tipo. Digamos que tienes una página llamada products page. En una página diferente, puedes importar el objeto routes de Blitz, y luego puedes referirte a la página de productos por nombre en lugar de proporcionar una cadena con una URL.

Así que si quieres comenzar con Blitz, puedes instalarlo globalmente y luego ejecutar el comando Blitz new. Necesitarás pasar un nombre para tu proyecto, y luego te hará algunas preguntas. Por ejemplo, si prefieres JavaScript o TypeScript, qué biblioteca de formularios quieres usar, y cuál es tu gestor de paquetes preferido. Hasta ahora, he estado hablando principalmente sobre el framework Blitz tal como es ahora, pero ahora déjame contarte sobre el futuro del toolkit Blitz. A finales del año pasado, Brandon, el creador de Blitz, anunció el cambio de Blitz. El plan es moverse hacia un toolkit agnóstico de framework que preserve toda la experiencia del desarrollador que Blitz tiene y todas las características que los desarrolladores aman de Blitz, pero queremos llevarlo no solo a los usuarios de Next.js, sino también a Remix, Spaltkit, Nuxt, y así sucesivamente. Esta fue una decisión enorme, y fue un gran cambio para la comunidad de Blitz. Mientras leíamos los comentarios y revisábamos lo que la gente decía sobre el cambio, solo nos hizo más seguros de que esta es la decisión correcta. Los comentarios fueron muy, muy positivos, y la mayoría de la gente dijo que esta es la mejor dirección para Blitz. Así que Blitz es un proyecto comunitario y valoramos la comunidad de nuestro código, por lo que no podríamos haber tomado esta decisión si no fuera por estos comentarios, y si no fuera por la gente diciéndonos que esta es la mejor elección. Así que podrías preguntarte por qué siquiera comenzamos a pensar en ello. Así que más de 100,000 proyectos fueron creados con Blitz y recientemente, hace unos meses, pasamos el hito de 10,000 estrellas en GitHub. Blitz recibió toneladas de comentarios positivos, y la gente decía que los hizo súper, súper productivos. Sin embargo, como mencioné antes, esto se basa en Next. Además, hace unos meses bifurcamos el repositorio de Next.js, lo cual por un lado fue una buena decisión porque nos permitió eliminar algunos pasos de compilación personalizados y nos permitió conectarnos directamente al código de Next. Por otro lado, nos ralentizó ya que la migración a la bifurcación estaba tomando tiempo y estábamos poniéndonos al día con Next.js. Tienen un gran equipo y hacen un montón de cosas increíbles, así que es un poco difícil mantenerse al día. El crecimiento de Blitz se estancó un poco, y estamos muy ansiosos por mejorar eso. Así que hablemos de los objetivos del cambio.

Nuestro objetivo es preservar la experiencia del desarrollador tanto como sea posible. No queremos hacer cambios en la API que no sean necesarios, y no queremos cambiar las características existentes. Nuestro objetivo, el objetivo principal, es llevar a más personas a Blitz o llevar Blitz a más personas. Queremos permitir a los desarrolladores usar algunas partes de Blitz, incluso si no quieren otras partes o incluso si no usan Next.js. Dicho esto, queremos desacoplar Blitz de cualquier framework o entorno de ejecución específico. Nos gustaría trabajar con Dino, Cloudflare workers, y no solo con Node.js.

Por último, queremos ofrecer más y más características increíbles sin centrarnos en mantener Next.js. Así que comparemos un poco y expliquemos cómo exactamente el nuevo Blitz será diferente del antiguo. Puedes pensar en el Blitz actual como un bug con características como cero API, recetas, autenticación, código de nuevo, y todo se basa en Next.js. Mientras que con el nuevo toolkit, puedes tomar aquellas partes que te interesen. ¿Quieres una API cero, pero no quieres autenticación? Está bien. ¿O tal vez no quieres una API cero, pero te gustaría la autenticación que esto proporciona? Eso también está bien y es posible. Y además de eso, la base puede ser un framework de tu elección. Así que repasemos las características del toolkit que planeamos tener. Creemos que el valor central que Blitz tiene actualmente es la capa de datos de cero API, la autenticación con autorización, todas las convenciones que tenemos, la nueva aplicación y el andamiaje de código.

Así que el nuevo toolkit está destinado a tener todas esas características también. Y planeamos agregar algunas cosas adicionales como autenticación JWT y, por ejemplo, una autorización más avanzada consciente de los datos. Pero eso no es todo. Hay muchas otras características que el nuevo toolkit podría soportar, como WebSockets, procesamiento en segundo plano, integración de correo electrónico, y muchas, muchas, muchas más. De hecho, si tienes alguna idea, puedes hacérnosla saber después de la masterclass.

Probablemente te preguntes, ¿qué pasa con todos los proyectos actuales de Blitz? Como mencioné, hay muchos de ellos. Así que las aplicaciones existentes de Blitz seguirán funcionando y corregiremos cualquier error crítico que surja. Haremos lanzamientos cuando sea necesario. Y tendremos Blitz en una especie de modo de mantenimiento durante el tiempo que necesitemos. También estamos trabajando para que la nueva configuración sea lo más cercana posible a la configuración actual. Para cualquier cambio requerido, tendremos un modo de código que automatizará algunos de esos cambios, si no todos. Así que el esfuerzo por parte del usuario debería ser lo más mínimo posible.

Para los proyectos existentes, queremos que la migración sea lo más fluida posible con los modos de código establecidos y la automatización. Así que hablemos ahora de la configuración del toolkit de Blitz. Te mostraré un montón de fragmentos de código, y puedes pensar en ellos como una especie de trabajo en progreso del código. No son finales. Esto es algo de lo que estábamos hablando, pensando, algo que estamos evolucionando alrededor. Pero es más o menos lo que queremos tener al final.

Así que vamos a tener una función setupServer, que devuelve un montón de cosas. Por ejemplo, un setupClient, una utilidad para inicializar la parte del cliente de Blitz. También devuelve funciones de API de GCCP, GCP, que serán envoltorios para los getServerSiteProps, getStaticProps, y manejadores de API de Next.js. Y también devuelve un tipo, BlitzServer, que puedes usar para tipar. Por ejemplo, puedes usarlo para proporcionar a la función setupClient. También el setupServer acepta una lista de plugins. El primero en este ejemplo es AuthPlugin. Toma una configuración para establecer un prefijo de cookie y un almacenamiento flotante para manejar la gestión de la base de datos de sesiones.

También podrías pasar el plugin de cero API con su propia configuración, y posiblemente algunos otros plugins como, por ejemplo, FileUploadPlugin. Así que en el cliente, tendremos la función setupClient, como mencioné antes. Y aquí también pasaremos todos los plugins que queremos tener en el lado del cliente. Devolverá un montón de utilidades del cliente como UseQuery, UseMutation, UseSession, con componentes de orden superior de Blitz para envolver toda tu aplicación. Nuestro queryClient para configurar la consulta de React, y así sucesivamente.

Aquí hay una interfaz de plugin del cliente. Así que esto es también más un pseudocódigo, pero tendrá eventos, algo que debería suceder en sessionCreate y sessionDestroy, para que otros plugins puedan conectarse al AuthPlugin. Tendrá middleware, así que cosas que deberían suceder antes de la solicitud HTTP y después de la solicitud HTTP exporta, todas las funciones que serán exportadas desde el plugin, como, ya sabes, UseQuery y UseMutation serán exportadas desde el plugin de cero API, o UseSession será exportado desde el AuthPlugin. También puede tener withProvider, un componente de orden superior, que se usará para envolver la aplicación.

Ahora, veamos más de cerca la capa de cero API y cómo podría funcionar con el toolkit de Blitz. Tenemos un montón de objetivos para ello. En primer lugar, queremos que sea una biblioteca independiente, que sea agnóstica al tiempo de ejecución y al framework. Usaremos HTTP GET para consultas, porque actualmente tanto las consultas como las mutaciones usan HTTP POST. Queremos soportar múltiples resolvers en un solo archivo, y lo más importante, queremos preservar la API actual tanto como sea posible. Idealmente, nada debería cambiar en la forma en que escribes los resolvers. Así que aquí hay un resolver de ejemplo, que se ve exactamente igual que en el actual framework de Blitz. Lo importaremos en un archivo de configuración de Blitz y lo pasaremos a la función setup server, específicamente a la configuración de cero API. Y luego en UseQuery, pasaremos una cadena con el nombre del resolver. Sin embargo, esa es solo una proposición.

Consideramos fuertemente mantener la importación mágica para que no tengas que importar los resolvers al archivo de configuración, y podrás importarlos directamente a las funciones UseQuery o UseMutation. Creemos que podemos hacer esto con un plugin de webpack personalizado, y eso es algo que estamos investigando actualmente. Entonces, ¿en qué estamos trabajando actualmente? El sistema de plugins, ya que es la parte más crucial, queremos hacerlo bien para que no nos bloquee en el futuro y no nos impida agregar soporte adicional para frameworks. También queremos que sea fácilmente expandible para que las personas puedan escribir sus propios plugins. Al mismo tiempo, estamos extrayendo algo de código de Blitz para una mejor comprensión de cómo todo debería funcionar junto. También configuramos un nuevo Monorepo en la rama principal en el repositorio de Blitz.

Bien, conclusiones de esta charla. Puedes visitar el sitio web Blitzjs.com para aprender sobre Blitz, o también puedes revisar el repositorio. Está en la organización Blitz-js y se llama Blitz. Nos encantaría recibir tus comentarios, así que si tienes alguna opinión sobre el cambio de dirección o cualquiera de las características de Blitz háznoslo saber. Puedes unirte a la discusión en el repositorio de Blitz, o puedes contactarme a mí o a Brandon a través de Twitter o correo electrónico.

Muchas gracias por unirte, y si quieres ponerte en contacto, no dudes en hacerlo. Podemos seguir hablando sobre Blitz. Puedes encontrarme en Twitter, como dice alexandra. Muchas gracias. Hola, Alexandra. Hola. Hola a todos.

Entonces, Alexandra preguntó, ¿has usado Blitz antes? Y el 50% dijo que no, sí, el 32%, y el 18%, solo el 18% dijo que no había oído hablar de él. Así que tengo que decir, este es un número bastante bueno, ¿verdad? ¿32%? Sí, este es un número bastante bueno. Así que el 50% no usó Blitz, eso podría haber sido una buena introducción a Blitz, así que eso es agradable. Así que la gente no se aburrió. Pero para aquellos que sí usaron Blitz, espero que les guste el cambio de dirección y que usen el nuevo toolkit de Blitz. Y sí, el 80% no ha oído hablar. Creo que ese es un buen número, ya sabes, solo el 18%. Eso es bueno. Eso es bueno para Blitz. Si hacemos esta pregunta a la misma audiencia de nuevo mañana, entonces será 50-50, por supuesto.

Muy bien. Vamos a pasar a algunas de las preguntas de la audiencia. La primera pregunta es de Popilinga. ¿El proyecto Blitz sigue en beta? Sí, sí. Sigue en beta porque Blitz se inició inicialmente hace como dos años, y Brandon, el creador de Blitz, estuvo trabajando en ello con la comunidad por un tiempo. Luego lanzaron Alpha. Y unos meses después de Alpha, lanzaron Beta. Y la cosa es que luego, como algún tiempo después del lanzamiento de Beta, me uní. Y estábamos, en lugar de usar Next.js como una dependencia, bifurcamos Next.js y, ya sabes, eliminamos nuestro compilador personalizado. Y estábamos moviendo como si estuviéramos moviendo el código central de Blitz a Next.js. Y queríamos tenerlo todo hecho antes del lanzamiento estable. Y también teníamos algunas otras características en mente para completar antes del lanzamiento oficial 1.0.

Sin embargo, mientras tanto, decidimos cambiar de dirección por las razones que mencioné en la charla. Queríamos llevar Blitz a más personas que usan otros frameworks, no solo Next.js. Así que por eso el framework está en beta.

¿Y hay una fecha estimada para la 1.0? Así que no estaremos trabajando en el framework en sí. No nos centraremos en eso. Simplemente cambiamos nuestro enfoque al 100% hacia el toolkit. Tal vez no al 100%, porque todavía estamos corrigiendo errores. Todavía estamos haciendo lanzamientos del framework. Porque, ya sabes, muchas personas lo están usando y queremos mantenerlo. Si alguien envía un PR, también dedicamos algo de tiempo a revisarlo. Pero sí, en cuanto a cosas más grandes como el lanzamiento de la 1.0, planeamos tener el toolkit como 1.0, como el nuevo Blitz oficial y estable. Sí, eso es lo que quise decir, lo siento. Sí, la fecha estimada. Así que estamos apuntando a finales de marzo. Ahora mismo tenemos algunas cosas funcionando. Puedes revisar la rama principal en el repositorio de Blitz. Tenemos algo de trabajo en progreso. Y sí, planeamos terminarlo en las próximas semanas. Eso es bastante emocionante. Sí, eso es emocionante. Cinco, seis semanas más, finales de marzo. Sí, mejor me apresuro y, ya sabes, vuelvo. Sí, me iré. Adiós.

La siguiente pregunta es bastante buena para las personas que quieren comenzar un nuevo proyecto mañana. ¿Recomendarías elegir Blitz o la gente debería mantenerse alejada hasta que se complete el Bifid? Así que todavía recomendaría usar Blitz porque, ya sabes, es un framework utilizado por muchos desarrolladores. Y aunque no es 1.0, es bastante estable y te da mucho poder como desarrollador full stack. Y, ya sabes, aunque estamos trabajando en el toolkit, queremos hacer esta transición realmente fluida. Así que habrá modos de código, también estaremos trabajando en ellos. Así que, ya sabes, cuando realmente tengas un proyecto Blitz y tengamos el toolkit listo, debería haber un comando que convierta el proyecto Blitz a un Next.js con el toolkit de Blitz.

Y tal vez haya alguna configuración en tu sitio, algunos pasos manuales, pero quieres tenerlos lo más limitados posible. Queremos, ya sabes, cubrir automáticamente casi todo para ti con modos de código y demás. Sí, eso es bueno porque de lo contrario es demasiado peligroso o aterrador elegir Blitz ahora. Así que es muy bueno que estés trabajando en estos modos de código. Gracias.

¿Y cuáles son algunas de las nuevas características que agregarás al framework de Blitz? ¿O agregarás alguna? Sí, así que no agregaremos nuevas características al framework de Blitz porque queremos enfocarnos tanto como sea posible en el toolkit. Sin embargo, todavía nos gustan las cosas pequeñas, todavía aceptamos PRs. Así que si hay algo pequeño que haría que el Blitz actual sea mejor y no requerirá muchas horas, como horas de revisión, y es como, ya sabes, solo PR y podemos enviarlo, entonces todavía estamos agregando ese tipo de cosas. No estamos trabajando activamente en las características del framework, pero posiblemente el nuevo toolkit venga con nuevas características desde el primer momento. Como, ya sabes, en el framework de Blitz, no teníamos autenticación de autorización JWT, pero tal vez lo tengamos desde el primer día en el toolkit. Así que puedes esperar ese tipo de cosas en el toolkit. Tal vez, pero este tal vez es en cinco semanas. Así que creo que tuvimos un vistazo del futuro aquí.

Sí, lo hicimos. Genial. Siguiente pregunta de Hail of the Wood. De todas las cosas en la hoja de ruta para el toolkit de Blitz, ¿qué es lo que más te emociona trabajar? ¿En qué estoy más emocionado de trabajar? Así que esa es una buena pregunta. Así que, ya sabes, como la parte más complicada de todo el toolkit y algo en lo que tuvimos que pasar mucho tiempo inicialmente es el diseño del sistema de plugins, como cómo hacer este nuevo toolkit de Blitz para que haya plugins y la gente pueda usar solo algunos de esos plugins como alguien quiere autenticación de Blitz, pero no quieren nada más o algo más y cómo hacerlo bien para que la gente pueda escribir sus propios plugins y demás. Así que ese fue como el desafío. Y otro desafío además de eso fue cómo hacer que esos plugins sean agnósticos al framework. Así que eso fue algo emocionante, como descubrir esto. Así que inicialmente pasé algún tiempo configurando un Next.js, como una aplicación simple de Next.js y trabajando en un esqueleto de cómo podría funcionar este sistema de plugins. Y eso fue bastante emocionante porque entonces pude ver, oh, así que necesito este tipo de cosa porque esta autenticación funciona de esta manera y posiblemente necesito que el plugin funcione de esta manera porque el 0 API funciona de esta manera y demás. Así que eso fue desafiante y emocionante. Sí. Sí, genial. Sí, es una buena manera de construir lo que necesitas, simplemente siendo tu propio cliente básicamente y ves que cobra vida lo que necesitas. Sí, genial.

Sí, a veces tenemos que experimentar. Exactamente.

Tenemos tiempo para una pregunta y respuesta rápida. Esta es de JSFirewatch69. Como framework para desarrolladores full stack, Blitz.js me recuerda a Meteor.js. ¿Fueron inspiradores para ti? Así que no estoy seguro si eso fue una inspiración para Brandon inicialmente. Sé que una gran inspiración fue Ruby on Rails. Y creo que, ya sabes, la idea era tener algo como Ruby on Rails en el mundo de JavaScript. Así que creo que con respecto a esta inspiración en particular, esa sería la pregunta para Brandon. Puedo preguntarle, ya sabes, rápidamente después de este chat y hacerte saber. Si puedes responder en Discord a JSFirewatch, entonces eso sería genial.

Sí. Así que eso es todo el tiempo que tenemos para la sesión de preguntas y respuestas en vivo. Pero si quieres continuar discutiendo Blitz.js con Alexandra, puedes hacerlo en su sala de oradores en Spatial Chat, donde ella irá en un minuto. Así que Alexandra, muchas gracias por unirte a nosotros. Ha sido un placer. Sí, gracias. Gracias por invitarme. Adiós.