Un vistazo al futuro del desarrollo fullstack con Blitz.js

Hoy hablaré sobre el futuro del desarrollo web full-stack con Bleeds.js. Te presentaré lo que Bleeds es actualmente y te daré un vistazo de lo que será en el futuro. Mi nombre es Aleksandra y actualmente estoy manteniendo Bleeds, y anteriormente lideré un equipo de la consola de Hasura. Puedes encontrarme en GitHub y Twitter, y también puedes visitar mi sitio web personal.

La agenda para hoy es hablar sobre el pasado, el estado actual y el futuro de Bleeds. Repasaremos los conceptos y características principales, y luego explicaré nuestros planes y en qué estamos trabajando actualmente. Algunos de ustedes pueden haber oído hablar de Bleeds, o tal vez incluso lo hayan usado en sus proyectos. Para aquellos que no lo conocen, Bleeds es un framework de React full-stack. Fue fuertemente 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 React. Bleeds se construye sobre Next.js. Next es un framework principalmente enfocado en el frontend, donde Bleeds 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, Bleeds utiliza Prisma, de forma predeterminada. Es un framework con baterías incluidas, lo que significa que todas las cosas aburridas como Slint, Pretier, Husky, TypeScript, Jest, ya están configuradas para ti. Puedes ir directamente a escribir la lógica de negocio y lanzar tus productos.

Uno de los conceptos principales es que Bleeds es monolítico. Esto significa que puedes pensar en tu aplicación como una entidad única. Solo hay una cosa para desarrollar, implementar y tener en cuenta. Ahora, hablemos de algunas de las características principales. La más importante es la capa de API cero. 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 debe realizar en el servidor. Necesitas una API, incluso si no va a ser utilizada por terceros aparte de tu propia aplicación. Los tiempos de compilación también son una fuente de complejidad y a veces se pueden evitar. BLEEDS te permite ejecutar código del servidor directamente desde tu frontend. ¿Cómo sucede esto? BLEEDS abstrae la API en un paso de compilación. Puedes usar la función SERVER en tu frontend y BLEEDS reemplazará la importación con una llamada HTTP en tiempo de compilación. Las funciones del servidor se llaman resolutores de BLEEDS y tenemos consultas y mutaciones. Sin embargo, son solo funciones JavaScript simples, que siempre se ejecutarán solo en el servidor. También puedes agregar tu propia API si es necesario, y BLEEDS no te impedirá hacerlo. Echemos un vistazo al diagrama de arquitectura.

En la parte superior, tenemos código del cliente y en la parte inferior tenemos código del servidor. En particular, tenemos una consulta y una mutación en la parte inferior. En tu 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. Con BLEEDS, pueden utilizar el mismo código del servidor. En el momento de compilación, se genera e inserta la capa intermedia automáticamente para ti.

La capa intermedia es esta API JSON generada automáticamente 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 una aplicación móvil. Aquí tenemos una muestra de consulta de BLEEDS, se llama GetProject. Y veamos qué sucede aquí. Usamos eso para definir la forma de los parámetros de la consulta. Luego analizamos la entrada para asegurarnos de que sea lo que queremos. Más adelante, hay una llamada a la database, aquí usamos Prisma. Y con esta llamada, intentamos encontrar el proyecto con un ID dado. Al final, la consulta devuelve el proyecto que estábamos buscando en la database.

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, una gran experiencia de desarrollo y muchas, muchas más características. Ahora veamos un 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 database para crear un nuevo objeto y al final, devolvemos el proyecto recién creado. En un componente de React, pasamos esta función a una useMutation y luego la usamos al enviar un formulario.

Otra gran ventaja de 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 al instante. Todo el código necesario para crear nuevas cuentas para iniciar sesión y cerrar sesión ya está generado para ti. También hay un adaptador Passport.js, que te permite agregar un inicio de sesión de terceros.

Aquí podemos ver la mutación de registro proporcionada en los proyectos de Blitz. Este código ya está presente después de crear una nueva aplicación de Blitz. Entonces, ¿qué tenemos aquí? Hashamos la contraseña con una utilidad segura de contraseñas 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 hashada. 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 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, esta es uno de los métodos, podemos usar la función de autorización. Entonces, si el usuario no está autenticado o no está autorizado para acceder a un recurso, lanzará un error.

Blitz también cuenta con andamiaje de código. Puedes usar la línea de comandos de Blitz para generar modelos, resolutores y páginas. Por ejemplo, con el comando Blitz generate all project, creamos páginas para listar, agregar y editar nuevos 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 en su mayoría inspiradas por Gatsby, y nos proporcionan una forma fácil de extender nuestras aplicaciones. Tenemos un montón de recetas en Blitz, y nos permiten, por ejemplo, agregar bibliotecas de interfaz de usuario, herramientas de registro de implementación y algunas cosas más.

Entonces, otra característica genial que Blitz introdujo son las rutas seguras por tipo. Digamos que tienes una página llamada Página de Productos. En una página diferente, puedes importar el objeto de rutas de Blitz, y luego puedes hacer referencia a la Página de Productos por nombre en lugar de proporcionar una cadena con una URL. Entonces, si quieres comenzar con Blitz, puedes instalarlo globalmente y luego ejecutar el comando Blitz new. Deberás proporcionar 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 administrador de paquetes preferido. Hasta ahora, he estado hablando principalmente sobre el marco de Blitz tal como es ahora. Pero ahora, déjame hablarte sobre el futuro de Blitz Toolkit. A finales del año pasado, Brandon, el creador de Blitz, anunció el cambio de rumbo de Blitz. El plan es pasar a un conjunto de herramientas independiente del marco que conserve toda la experiencia de desarrollo 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, Speltkit, Nuxt y otros más.

Esta fue una decisión enorme, enorme, y fue un cambio enorme para la comunidad de Blitz. A medida que leíamos los comentarios y revisábamos lo que la gente decía sobre el cambio de rumbo, solo nos convencía más de que esta es la decisión correcta. La retroalimentación fue muy, muy positiva. Y la mayoría de las personas dijeron que esta es la mejor dirección para Blitz.

Entonces, Blitz es un proyecto de comunidad y valoramos la comunidad por encima del código, por lo que no podríamos tomar esta decisión si no fuera por esta retroalimentación, y si no fuera porque la gente nos decía que esta es la mejor opción. Puede que te preguntes por qué siquiera comenzamos a pensar en ello. Se crearon más de 100,000 proyectos con Blitz, y recientemente, hace unos meses, superamos el hito de las 10,000 estrellas en GitHub. Blitz recibió toneladas de comentarios positivos y la gente decía que les hacía ser muy, muy productivos. Sin embargo, como mencioné antes, esto se basa en Next.

¿Qué má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 llevaba tiempo. Y estábamos alcanzando a Next.js. Tienen un gran equipo y hacen un montón de cosas increíbles. Así que es un poco difícil mantenerse actualizado. El crecimiento de Bleed se ha estancado y estamos ansiosos por mejorarlo.

Entonces, hablemos de los objetivos del cambio de rumbo. Nuestro objetivo es preservar la experiencia del desarrollador tanto como sea posible. No queremos realizar cambios en la API que no sean necesarios. Y no queremos cambiar las características existentes. Nuestro objetivo principal es atraer a más personas a Bleed o llevar Bleed a más personas. Queremos permitir a los desarrolladores utilizar algunas partes de Bleed, incluso si no desean otras partes o incluso si no usan Next.js. Dicho esto, queremos desvincular Bleed de cualquier marco o tiempo de ejecución específico. Nos gustaría trabajar con Deno, Cloud for Workers y no solo con Node.js. Por último, queremos lanzar más y más características increíbles sin centrarnos en mantener Next.js. Comparemos un poco y expliquemos cómo será exactamente el nuevo Bleed diferente al anterior. Puedes pensar en el Bleed actual como un paquete con características como API cero, recetas, autenticación, generación de código, y todo se basa en Next.js. Mientras que con el nuevo conjunto de herramientas, puedes tomar esas partes en las que estás interesado. ¿Quieres una API cero pero no quieres autenticación? Eso está bien. ¿O tal vez no quieres una API cero pero te gusta la autenticación que Bleed proporciona? Eso también está bien y es posible.

Y además de eso, la base puede ser un marco de su elección. Así que repasemos las características de la herramienta que planeamos tener. Creemos que el valor principal que tiene actualmente es la capa de datos de API cero, la autenticación con autorización, todas las convenciones que tenemos, la nueva aplicación y la generación de código. Entonces, la nueva herramienta está destinada a tener todas esas características también, y planeamos agregar algunas cosas adicionales como autenticación JWT y, por ejemplo, autorización avanzada basada en datos. Pero eso no es todo, hay muchas otras características que la nueva herramienta podría admitir, como websockets, procesamiento en segundo plano, integración de correo electrónico y muchas más.

De hecho, si tienes alguna idea, puedes hacérnosla saber después de la charla. Probablemente te preguntes, ¿qué pasa con todos los proyectos actuales de BLEEZ? Como mencioné, hay muchos de ellos. Por lo tanto, las aplicaciones existentes de BLEEZ seguirán funcionando y corregiremos cualquier error crítico que surja. Realizaremos lanzamientos cuando sea necesario y tendremos BLEEZ en algún tipo de modo de mantenimiento el tiempo que sea necesario. También estamos trabajando para que la nueva configuración sea lo más similar 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. Por lo tanto, 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.

Entonces, hablemos ahora de la configuración de la herramienta BLEEZ. 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 definitivos. Esto es algo de lo que hemos estado hablando, pensando, algo en lo que estamos evolucionando. Pero es más o menos lo que queremos tener al final. Así que vamos a tener una función setupServer, que devuelve varias cosas. Por ejemplo, un setupClient, una utilidad para inicializar la parte del cliente de Bleeds. También devuelve las funciones gcp, gcpAPI, que serán envoltorios para GetServerSideProps, GetStaticProps y los controladores de API de Next.js. También devuelve un tipo BleedsServer, que puedes usar para tipar. Por ejemplo, puedes usarlo para proporcionarlo a la función setupClient. Además, la función setupServer acepta una lista de complementos. 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 sesión en la base de datos. También podrías pasar un zeroAPIPlugin con su propia configuración y posiblemente otros complementos como, por ejemplo, FileUploadPlugin. Así que en el cliente, tendremos la función setupClient, como mencioné antes. Y aquí también pasaremos todos los complementos que queremos tener en el lado del cliente.

Devolverá un conjunto de utilidades del cliente como useQuery, useMutation, useSession, con componentes de orden superior de Blitz para envolver toda su aplicación, QueryClient para configurar la consulta de React, y así sucesivamente. Aquí está la interfaz del complemento del cliente. Así que esto también es más bien un seudocódigo, pero tendrá eventos, algo que debería ocurrir en SessionCreate y SessionDestroy, para que otros complementos puedan conectarse al complemento de autenticación. Tendrá middleware, por lo que habrá cosas que deberán ocurrir antes y después de la solicitud HTTP, exportaciones, todas las funciones que se exportarán desde el complemento, como useQuery y useMutation que se exportarán desde zeroAPIPlugin, o useSession que se exportará desde el complemento de autenticación. También puede tener withProvider, un componente de orden superior que se utilizará para envolver la aplicación.

Ahora, veamos más de cerca la capa zeroAPI y cómo podría funcionar con el Blitz Toolkit. Tenemos una serie de objetivos para ello. En primer lugar, queremos que sea una biblioteca independiente que sea agnóstica en cuanto a tiempo de ejecución y marco de trabajo. Utilizaremos HTTP GET para las consultas, porque actualmente tanto las consultas como las mutaciones utilizan HTTP POST. Queremos admitir múltiples resolutores 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 resolutores.

Aquí tienes un ejemplo de resolutor, que se ve exactamente igual que en el marco de trabajo Blitz actual. Lo importaremos en un archivo de configuración de Blitz y lo pasaremos a la función de configuración del servidor, específicamente la configuración de zeroAPI. Y luego en useQuery, pasaremos una cadena con el nombre del resolutor. Sin embargo, esa es solo una propuesta. Consideramos seriamente mantener las importaciones mágicas para que no tengas que importar los resolutores al archivo de configuración y puedas importarlos directamente a las funciones useQuery o useMutation. Creemos que podemos hacer esto con un complemento personalizado de Webpack y eso es algo en lo que estamos investigando actualmente.

Entonces, ¿en qué estamos trabajando actualmente? El sistema de complementos, 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 marcos de trabajo. También queremos que sea fácilmente ampliable, para que las personas puedan escribir sus propios complementos. Al mismo tiempo, estamos extrayendo algo de código de Blitz para tener una mejor comprensión de cómo debería funcionar todo junto. También hemos configurado un nuevo monorepo en la rama principal del repositorio de Blitz.

De acuerdo, conclusiones de esta charla. Puedes visitar el sitio web blitzjs.com para obtener información sobre Blitz, o también puedes consultar el repositorio en blitz-js.org y se llama blitz. Nos encantaría recibir tus comentarios, así que si tienes alguna idea sobre el cambio de rumbo o alguna de las características de Blitz, háznoslo saber. Puedes unirte a la discusión en el repositorio de Blitz, o puedes ponerte en contacto conmigo o 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 de Blitz. Puedes encontrarme en Twitter como AlexandraSes. Muchas gracias.

Hola Alexandra. Hola. Hola. Hola a todos. Entonces, Alexandra preguntó, ¿han usado Blitz antes? Y el 50% dijo que no, el 32% dijo que sí y el 18% solo 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, ya sabes. Entonces, como el 50% no usó Blitz, esa charla podría haber sido una buena introducción a Blitz. Así que eso es bueno. Así que la gente no se aburrió. Pero para aquellos que sí usaron Blitz, espero que les haya gustado la idea de Pivot y que utilicen el nuevo Blitz Toolkit. Y sí, el 80% no había oído hablar de él. Creo que 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 mañana, entonces será 50-50, por supuesto. Sí.

Muy bien. Vamos a responder algunas preguntas de la audiencia. La primera pregunta es de Populinga. ¿El proyecto Blitz todavía está en fase beta? Sí. Sí. Todavía está en fase beta porque Blitz se inició inicialmente hace dos años y Brandon, el creador de Blitz, estuvo trabajando en él con la comunidad durante un tiempo. Luego lanzaron la versión Alpha y unos meses después de la Alpha, lanzaron la Beta. Y la cosa es que luego, después del lanzamiento de la Beta, me uní y en lugar de usar Next.js como una dependencia, bifurcamos Next.js. Y, ya sabes, eliminamos nuestro compilador personalizado. Estábamos trasladando el código principal de Blitz a Next.js. Queríamos tenerlo todo listo 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 pivotar por las razones que mencioné en la charla. Queríamos llevar Blitz a más personas que utilizan otros frameworks, no solo Next.js. Por eso el framework está en fase beta.

¿Y hay una ETA para la versión 1.0? No estaremos trabajando en el framework en sí, ya sabes, no nos enfocaremos en eso. Simplemente cambiamos nuestro enfoque al 100% en el toolkit. Tal vez no al 100%, porque aún estamos corrigiendo errores. Todavía estamos haciendo lanzamientos del framework, porque, ya sabes, mucha gente lo está utilizando y queremos mantenerlo. Si alguien envía un PR, también dedicamos tiempo a revisarlo. Pero, sí, en cuanto a cosas más grandes como el lanzamiento 1.0, planeamos tener el toolkit como 1.0, como, ya sabes, el nuevo Blitz estable oficial. Sí, eso es lo que quiero decir. Perdón. Sí, la ETA. Entonces, apuntamos a finales de marzo. Ahora mismo tenemos algunas cosas funcionando. Puedes revisar la rama principal en el repositorio de Blitz. Tenemos algunos trabajos en progreso. Y sí, planeamos terminarlo en las próximas semanas. Eso es bastante emocionante. Sí, es emocionante. Cinco, seis semanas más, finales de marzo. Sí, mejor me apuro y vuelvo. Sí, me voy, adiós adiós.

La siguiente pregunta es bastante buena. Para las personas que quieren comenzar un nuevo proyecto mañana. ¿Recomendarías elegir Blitz? ¿O deberían mantenerse alejados hasta que se complete el Biffin? Aún así, recomendaría usar Blitz porque es un framework utilizado por muchos desarrolladores. Y aunque no sea la versión 1.0, es bastante estable. Y te brinda mucho poder como desarrollador full stack. Y aunque estamos trabajando en el toolkit, queremos que esta transición sea realmente fluida. Habrá modos de código. También trabajaremos en ellos.

Entonces, cuando realmente tienes un proyecto de Blitz y tenemos el toolkit listo, debería haber un comando que convierta el proyecto de Blitz a Next.js con el toolkit de Blitz. Tal vez haya alguna configuración en tu sitio, algunos pasos manuales. Pero queremos que sean lo más limitados posible. Queremos cubrir automáticamente casi todo para ti con el modo de código y demás. Sí, eso es bueno porque de lo contrario sería demasiado peligroso o aterrador elegir Blitz ahora. Es muy bueno que estés trabajando en este modo de código. Gracias.

¿Y qué nuevas características agregarás al framework de Blitz? ¿O agregarás alguna? Sí, no agregaremos nuevas características al framework de Blitz porque queremos enfocarnos lo más posible en el toolkit. Sin embargo, aún aceptaremos pequeñas cosas, aún aceptaremos PR. Entonces, si hay algo pequeño que haga que el Blitz actual sea mejor y no requiera muchas horas de revisión, y es solo un PR y podemos enviarlo, aún agregaremos ese tipo de cosas. No estamos trabajando activamente en las características del framework. Pero posiblemente, el nuevo toolkit vendrá con nuevas características de serie, como en el framework de Blitz, no teníamos autorización JWT, autenticación. 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 esto tal vez sea en cinco semanas, así que creo que hemos tenido un vistazo al futuro aquí. Sí, lo hemos tenido. Genial.

Siguiente pregunta de Hail of the Wood. De todas las cosas en la hoja de ruta del toolkit de BLEACH, ¿en qué estás más emocionado de trabajar? ¿En qué estoy más emocionado de trabajar? Esa es una buena pregunta. La parte más complicada de todo el toolkit y algo en lo que inicialmente tuvimos que invertir mucho tiempo para descubrir es todo el diseño del sistema de plugins, cómo hacer que este nuevo toolkit de BLEACH permita tener plugins y que las personas puedan usar solo algunos de esos plugins, por ejemplo, alguien quiere autenticación de BLEACH, pero no quiere nada más o algo más, y cómo hacerlo bien para que las personas puedan escribir sus propios plugins, y así sucesivamente. Eso fue un desafío. Y otro desafío adicional fue cómo hacer que esos plugins sean independientes del framework. Así que eso fue emocionante, descubrirlo. Así que inicialmente invertí algo de tiempo en configurar una aplicación simple de next-js y trabajar en un esqueleto de cómo podría funcionar este sistema de plugins. Y eso fue bastante emocionante porque luego pude ver, oh, necesito este tipo de cosa porque esta autenticación funciona de esta manera y posiblemente necesito que el plugin funcione de esta manera porque la API de Xero funciona de esta manera. Y eso fue desafiante y emocionante. Sí, genial. Sí, es una buena manera de construir lo que necesitas, siendo tu propio cliente básicamente, y ver cómo cobra vida lo que necesitas. Sí, genial.

Sí, a veces tienes que experimentar. Exactamente, tenemos tiempo para una pregunta y respuesta rápida. Esto es de JSfire, Watch69. Como un framework para un desarrollador full stack, Blitz, sí, me recuerda a Meteor. Sí. ¿Fueron una inspiración para ti? Entonces, 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 en cuanto a esta inspiración en particular, esa sería la pregunta para Brandon. Puedo preguntarle, ya sabes, rápidamente después de esta sección. Y eso, ya sabes. Si puedes ingresar al Discord de JS Firewatch, eso sería genial. Sí. Eso es todo el tiempo que tenemos para la sesión de preguntas y respuestas en vivo, pero si quieres seguir discutiendo Blitz, sí, con Alexandra, puedes hacerlo en nuestra sala de oradores en Spatial Chat, donde ella se dirigirá en un minuto. Así que Alexandra, muchas gracias por unirte a nosotros. Ha sido un placer. Sí. Gracias por recibirme. Adiós. Adiós. Adiós. Adiós. Adiós Adiós Gracias por recibirme. Adiós. Adiós. Adiós. Adiós.