De GraphQL Zero a GraphQL Hero con RedwoodJS

♪♪ ♪♪ ♪♪ Hola a todos. Tom Pressenwurter aquí con una simple pregunta para ustedes. ¿Cuál es la forma más fácil de poner en marcha una API de GraphQL? A todos nos encanta GraphQL, pero a veces puede parecer un poco desalentador poner en marcha un proyecto. Y aquí hay otra pregunta. ¿Puede ser fácil y sostenible? ¿Puedes mantener las cosas de manera ordenada a largo plazo? Bueno, ahí es donde entra Redwood.js. Redwood.js es un marco de aplicación de pila completa, perfecto para todo, desde prototipos rápidos hasta la construcción de startups. He estado trabajando en ello durante los últimos dos años, y creo que se ha convertido en algo realmente útil, tanto en el front end como en el back end.

Permíteme mostrarte cómo se ve una aplicación Redwood.js. En el front end, tenemos una aplicación web, una aplicación de una sola página, basada en React. Y en el back end tenemos una API basada en Node.js escrita en JavaScript o TypeScript. El front end se comunica con el back end utilizando el Cliente Apollo y habla GraphQL con el back end donde utilizamos GraphQL Helix y Envelop para crear el servidor GraphQL.

En tu lógica de negocio, utilizarás Prisma para comunicarte con una base de datos. Aunque Redwood.js proporciona el front end y el back end, hoy me voy a centrar principalmente en el back end y en la creación de la API GraphQL. Así que vamos a ver un poco de código.

Bien, lo primero que voy a hacer es crear una nueva aplicación Redwood.js utilizando yarn create Redwood app, y voy a hacer una sencilla aplicación de música. Así que la voy a llamar tracks. Esto va a buscar todas las dependencias. Ejecutar yarn install, etc. Normalmente tarda un poco, así que permíteme acelerar eso para ti. Ahí vamos. Voy a entrar en ese directorio y voy a abrir VS código desde allí. Lo primero que voy a hacer, voy a abrir una ventana de terminal aquí y voy a convertir esto en un repositorio git para que puedas ver más fácilmente qué archivos estoy cambiando.

Bueno, aquí está la estructura de carpetas de una aplicación Redwood.js. Tenemos el sitio web del que hablé en el front end y tenemos la API del backside. Y aquí, podemos encontrar en la carpeta DB, schema.prisma. Este es el archivo de esquema Prisma que nos va a decir cómo se ve nuestra database.

Hay algunos datos de muestra aquí. Para mí, quiero tener una tabla de artistas y eso solo va a tener un nombre que es una cadena y también voy a tener una tabla de álbumes que contendrá información del álbum. Eso va a tener un ID, que es un int, es un ID y se autoincrementará y va a tener un título que es una cadena y va a tener un número de likes, que es un int.

Ahora, quiero poder conectar estos dos para que mis artistas puedan tener varios álbumes. Así que, voy a decir, voy a tener un álbum y eso va a ser un array de álbumes. Cuando guardo esto, boom, obtenemos algunas cosas bonitas que Prisma hace por nosotros. Así que conectará estos dos por nosotros y solo voy a renombrar lo que llama a esto y voy a decir que siempre va a tener una de estas conexiones. Así que, eso es todo por ahora, solo un artista y un número de álbumes como esquema.

Ahora, iniciemos nuestra aplicación para que podamos ver cómo se ve. Realmente no hemos hecho mucho todavía. El esquema aún no existe en una database pero solo inicia la aplicación, ejecutaremos yarn redwood dev. Esto va a iniciar tanto el backend como el front end para que podamos ver la aplicación completa conectada y estaremos principalmente interesados en el backend en esta charla pero es útil saber que el front end existe. Así que aquí está el front end. Por ahora, es solo un marcador de posición. El backend vive en el puerto 8911 slash GraphQL y aquí podemos ver el esquema de lo que ya está allí. Hasta ahora, no hay demasiado. Algunos escalares, algunas cosas de introspección. Realmente no hay mucho pasando aún como esperaríamos.

¿Entonces, qué queremos hacer a continuación? Tenemos nuestro esquema. Necesitamos poner eso en una database. Así que ejecutemos una migración para hacer eso. Así que ejecutaré YARN Redwood Prisma porque estamos usando Prisma. Migrate-dev y eso va a tomar nuestro esquema, va a ver qué cambió y va a crear una migración para eso y lo pondrá en una carpeta de migraciones que aparecerá aquí en un segundo una vez que le dé un nombre. Y aquí está. Así que voy a decir añadir artista y álbum. Así que ahora creará esta carpeta de migraciones para nosotros.

Esto nos permite desplegar fácilmente estas migraciones en un servidor de producción eventualmente. Y ahora tenemos el esquema establecido dentro de la database.

Muy bien. Pero no es muy interesante hasta que haya algunos data. Así que podemos poner algunos data, algunos datos de muestra en la database usando este archivo de semillas aquí. Tengo a mano algunos datos de semillas aquí. Así que voy a borrar este archivo. Voy a pegar el mío. Estos son solo un montón de datos de muestra que se van a introducir allí. Y puedo introducir eso en la database usando yarn redwood prisma db seed. Así que eso ejecutará ese archivo e introducirá esos datos de muestra en la database para que podamos jugar con ellos. Ahí vamos. Eso está hecho.

Y ahora necesitamos una forma de mirar los data. Y sería útil tener algunas funciones GraphQL para poder listar y quizás crear nuevas. Afortunadamente, Redwood JS tiene exactamente lo que necesitamos. Así que ejecutaremos yarn redwood g para generar, y vamos a crear un andamio, que va a ser el material en el front-end y el back-end para crear las operaciones CRUD que nos pondrán en marcha. Luego podemos modificar desde allí. Así que crearé un andamio para el artista, y crearé uno para el álbum.

Y ahora que los tenemos, veamos en nuestro GraphQL de nuevo en nuestro esquema. Verás ahora que hay muchas más cosas allí. Así que tenemos un montón de consultas sobre álbumes y artistas, así como la creación y eliminación y actualización. Así que ejecutemos una de ellas y veamos lo que tenemos. Veamos los álbumes y podemos decir, dame el título y el número de likes, ejecuta eso y aquí vamos. Ahora tenemos un montón de álbumes en la database con los que podemos jugar. Y tenemos funciones GraphQL para poder ver todo eso en un par de minutos. Esto es realmente lo que significa trabajar en el mundo de Redwood. Como tratamos de hacer todas estas cosas super fáciles. Realmente nos enfocamos en la developer experience, llevándote a donde quieres estar lo más rápido posible. Bueno, eso está bien y es bueno.

Tienes tu esquema, pero ¿qué generamos? ¿Es útil eso? Bueno, vamos a ver. Entonces, veamos en la fuente GraphQL álbumes. Y aquí encontramos el SDL. El GraphQL Schema Definition Language que representa cómo se ve nuestra API GraphQL. Así que vemos el tipo de álbum, tenemos algunas consultas y tenemos las otras cosas que ya has visto en el esquema.

De manera similar, tenemos otro archivo donde se define el artista. Y efectivamente puedes usar tipos a través de estas cosas. Los unimos para ti. Así que hacemos esta parte de la creación de una API GraphQL muy fácil. Organización realmente excelente. Todo está en su lugar. Todo está separado exactamente donde quieres que esté.

Entonces, ¿cómo se implementan? Veamos en los servicios. Un servicio es una parte de tu API GraphQL dividida por funcionalidad. Y aquí podemos ver, de nuevo, veamos los álbumes, albums.js. Y aquí verás un montón de funciones regulares exportadas. Cada una toma argumentos, tal vez. Y esto te resultará familiar. Se parece mucho a lo que podrías poner en tus resolvers, si estás creando un gran objeto resolver.

Lo bueno de Redwood.js es que automáticamente mapearemos los nombres de tus consultas y mutaciones en tu archivo SDL a funciones de JavaScript o TypeScript que se exportan. Entonces, por ejemplo, en el SDL, tienes la consulta de álbumes, y en la implementación del servicio albums.js, tienes una función de álbumes. Y así es como los emparejamos. Así que simplemente buscamos funciones exportadas con el mismo nombre, y así es como los mapeamos. Y verás por qué esto se vuelve importante más adelante.

Entonces, está bien, aquí está la implementación. Estas son simplemente esquemas, o lo siento, llamadas a Prisma que haces, cosas simples, no demasiado complicadas. Y si quieres cambiar estas cosas, puedes entrar y personalizar esto a tu gusto. Si quieres eliminar la capacidad de crear un álbum a través de GraphQL, simplemente puedes eliminar esta implementación, eliminar la declaración del SDL y ya está. Ahora veamos cómo se ve crear otra consulta. Entonces, vamos a los álbumes y digamos, quiero tener la capacidad de encontrar álbumes populares.

Así que voy a crear una nueva consulta llamada popAlbums, y va a devolver un array de album, y ninguno de ellos será nulo. Y voy a añadir esta directiva require auth en ella, que te mostraré para qué sirve más adelante. Está subrayado aquí porque dice que el servicio no está implementado. Así que tenemos algunas cosas bonitas que hacemos en VS Code para ayudarte. Y una de estas es para hacerte saber que, hey, has definido esto en el SDL, pero aún no has escrito el servicio para ello.

Muy bien. Así que vamos a escribir la implementación del servicio, el resolver para esto. Va a parecerse mucho a los álbumes. Así que vamos a exportar const popAlbums, y eso va a ser una función, sin argumentos. Y va a devolver la DB de la tabla de álbumes. Voy a encontrar muchos de esos. Y voy a, digamos que queremos ordenar todos los álbumes por likes, en orden inverso, descendente, y luego tomar los primeros 10 de esos. Así que con Prisma, podemos decir ordenar por, likes, descendente, y tomar los primeros 10 de esos. Así que vamos a guardar eso. Y vamos a ver si eso está ahora disponible después de que el servidor se recargue. Así que deberíamos esperar ver los álbumes pop, y efectivamente, ahí está. Y vamos a obtener el título y los likes, ejecutar eso. Y aquí vamos. Ahora tenemos algunos álbumes, y los likes están ordenados en orden descendente. Y veamos, solo hay 10 de ellos. Genial. Hemos implementado una nueva función, una nueva consulta GraphQL. Tan fácil como eso, tiene sentido. Exportamos una función. Es muy fácil de separar de todas las demás. Y es tan fácil como eso. Así es la magia de Redwood que has visto hasta ahora. Tan fácil como eso para poner en marcha tu API GraphQL, añadir algo a ella. Ahora vamos un poco más allá. Digamos que quiero añadir un nuevo servicio y añadir algo a eso, ¿verdad? Pero lo haré a mano esta vez.

Entonces, en nuestro GraphQL, voy a añadir algo. Lo llamaré info. Será nuestro servicio de información. Y allí todo lo que tenemos que hacer es, al igual que los otros, exportar una constante, se llama esquema. Y va a ser GQL, GraphQL. Y allí, tenemos nuestro tipo de consulta que se extenderá. Y quiero crear algo que nos devuelva un solo álbum, el álbum más popular. Así que lo llamaré el álbum superior. Y simplemente va a responder con un álbum y necesito mi directiva de autenticación requerida.

Entonces, guardemos eso. Es el error, no hay implementación. Así que vamos a darnos un pequeño atajo aquí. Y esto va a crear la implementación para nosotros y la esbozará ahora en el servicio de información. Limpiaré esto un poco, sin argumentos. Y entonces recuerdas cómo esas funciones que las funciones de resolución son ahora simplemente funciones regulares de JavaScript. Bueno, eso significa que podemos importarlas. Así que vamos a importar álbumes populares del servicio de álbumes. Y como ya tenemos eso disponible, simplemente saquemos el primero de ahí. Así que vamos a obtener todos los álbumes populares. Vamos a llamar a eso, tenemos que esperar porque es asíncrono. Y luego devolvamos álbumes cero y simplemente devolvamos el primero. Y por supuesto que solíamos esperar. Así que tenemos que hacer esta función asíncrona. Así que guardemos eso. Y ahora esperaríamos después de que el servidor se reinicie que tendremos una nueva consulta llamada álbum superior. Y entonces veamos cuál es el título y el número de 'likes' que hay en él. Vaya, 'likes', en plural. Aquí vamos. Tenemos 9808 'likes', ese es el álbum superior tal como esperábamos. Eso fue bastante genial, ¿verdad? Así que podemos importar esas funciones de resolución y usarlas en otros lugares en los servicios. Así que realmente te da una forma de separar tu funcionalidad de backend, tu lógica de negocio de una manera lógica, lo que te da mantenibilidad a largo plazo y hace que sea realmente fácil de ver y entender lo que está pasando.

Otra cosa genial acerca de GraphQL es que, por supuesto, puedes recorrer cosas. Así que digamos que queremos saber quién es el artista y obtener su nombre, podemos ejecutar eso. Boom, ahí está su nombre. Y por supuesto podemos ir más profundo. Podemos decir, tal vez estoy en la página de inicio de mi aplicación y quiero mostrar el álbum más popular y recomendarte algunos de los álbumes relacionados. Así que diré, bueno, ¿cuáles son tus álbumes de este artista? Y quiero el título y el número de 'likes' para poder mostrarlos en la página de inicio. Y parece que nombré esto incorrectamente. En realidad se llama álbum. Bueno, aquí vamos. Ahora podemos ver los álbumes relacionados. ¿No te encanta GraphQL? Es genial, ¿no? Pero espera, hay más.

Hablemos de esas directivas que vimos. Así que recuerda los álbumes y la directiva require auth. Bueno, veamos qué hace. En Redwood, llamamos a estos servicios seguros. Eso significa que, por defecto, cada consulta y mutación de GraphQL que hagas va a estar asegurada. Ahora, no hemos instalado ninguna authentication y Redwood.js lo hace realmente fácil para añadir integraciones de autenticación de terceros como OAuth o Netlify Auth. O puedes crear la tuya propia y tenerla almacenada en tu propia database. Y tenemos una funcionalidad completa llamada dbouth para hacer eso.

Así que cuando haces eso, require auth realmente empezará a hacer algo. Ahora mismo, simplemente permitirá que todo pase como has visto aquí. No es necesaria ninguna authentication. Bueno, veamos cómo se implementa require auth. Y eso está aquí en la carpeta de directivas. Así que require auth entra, dice, así es como se ve en el SDL, esto se fusiona. Y esta es una directiva de validation, lo que significa que va a aceptar o rechazar tu acceso. Y aquí estamos llamando a esta aplicación require auth, que está aquí arriba y simplemente extrae algo de source lib auth, este require auth. Así que veamos eso. Source lib auth. Y aquí está require auth y llama a is authenticated, que simplemente devuelve true. Así que si entramos aquí y decimos, bueno, en lugar de hacer eso, voy a fingir ser un servicio de authentication. ¿Qué pasa si no estoy autenticado y voy a lanzar un nuevo error de authentication y simplemente va a decir, nope. Bueno, ahora esperamos que nuestras consultas no vayan a funcionar. Ahora hemos forzado que no hay, todo está sin autenticar. Así que intentemos ejecutar esto de nuevo. Y aquí vamos. Nope, sin autenticar, y ahora nada que use require auth va a funcionar. Así que digamos que queríamos obtener el álbum y obtener el título y los 'likes'. Nope, GraphQL dice nope, ¿verdad? Porque está detrás de require auth. Bueno, ¿y si no queremos authentication? ¿Qué pasa si esta consulta está en la página de inicio y no necesitas estar autenticado? Bueno, por eso tenemos otra directiva llamada skip auth. Así que la consulta de álbumes, digamos que puede saltarse la autenticación ahora porque está disponible al público.

Entonces, la consulta de álbumes, digamos que puede saltarse la autenticación ahora porque está disponible al público. Ahora ejecutemos esa consulta. Hey, ahí vamos. Funciona de nuevo. Entonces, la authentication se puede incorporar directamente en tus archivos SDL. Lo tienes disponible en una base muy detallada por consulta y lo verás en las mutaciones. Y eso luego se integra con todas nuestras técnicas de authentication, lo que lo hace súper fácil.

Entonces, ¿qué pasa si quieres crear la tuya? Hay otro tipo de directiva llamada directiva transformadora. Y te voy a mostrar lo que eso significa. Así que generemos una. Yarn redwood generate directive. Y digamos que quiero, si tienes una suscripción a mi servicio, entonces vas a obtener todos los data que quieras. Pero si no tienes una suscripción, entonces quiero limitar el número de registros que puedes obtener. Así que voy a llamar a esto un sub-limiter porque es un limitador de suscripción. Así que sub-limiter. Esto va a generar una nueva directiva. Tengo que decirle que quiero una directiva transformadora. Va a generar un stub para mí. Y aquí está. Entonces, quiero decir, esta es una implementación real. Tiene un montón de comentarios aquí, pero la mayor parte de ello es, hay una transformación, recibe el valor del resultado tal como está, y te permite modificarlo. Así que aquí, en lugar de fingir que esto es una cadena, que la mía no será, la mía será matrices, puedo decir, quiero cortarla y restringirla a solo tres elementos. Ahora, esto lo va a hacer para todos. Si tuviera un poco más de lógica aquí, podría decir, si context.currentUser, porque esto es, siempre puedes obtener el usuario actual, el usuario autenticado llamando a context.currentUser, . algo, algo, algo tiene suscripción, etc., que he implementado, entonces así es como lo hago aquí. No tengo eso. Esto solo va a restringir siempre. ¿Dónde voy a usar eso? Puedo usar eso en un álbum, en mi consulta de álbumes. Puedo decir, en lugar de dártelo todo, solo quiero que esté disponible para los suscriptores. Aquí vamos.

Agrega la directiva sum limiter a la consulta de álbumes, y ahora, en lugar de obtener todos los álbumes, de los cuales hay alrededor de 100, espero que esto se limite a tres. Y ahí vamos. Puedo tomar ciertos bits de implementación y puedo dividirlos de diferentes maneras y puedo adjuntarlos a través del SDL donde tenga sentido, lo cual es realmente útil y puede limpiar mucho tu code.

En lugar de poner todo eso en el archivo de servicios para cada cosa y replicarlo por todas partes, aquí está solo en el SDL. Y lo que es realmente genial es que puedo copiar eso y puedo decir, bueno, quiero que eso también sea cierto para álbumes populares. ¿Adivina qué? Solo obtienes tres. Así que puedo ponerlo allí y ahora puedo decir álbumes pop y esperaremos que de hecho yo, todavía no estoy autenticado allí porque no me salté, ¿recuerdas? Así que salta. Y ahora esa es una consulta pública que puedo hacer. Y veamos si funcionó también allí. Ejecutemos eso. Y aquí vamos. Ahora solo tengo tres álbumes que han sido devueltos.

Y desafortunadamente eso es todo el tiempo que tengo hoy, pero esto va mucho, mucho más profundo. Hacemos que sea fácil probar cada una de estas funciones que creas porque están aisladas. Puedes unit test muy fácilmente con las pruebas que generamos para ti aquí. Tenemos características advanced como limitación de profundidad para evitar que las personas abusen de tu servicio, toda la funcionalidad segura por defecto, integración de registro e incluso almacenamiento en caché muy pronto. Así que si te gusta lo que has visto y quieres aprender más, ve a redwoodjs.com, échale un vistazo, sigue nuestro proyecto en Twitter en redwoodjs. Y si quieres algunas pegatinas gratis, que sé que quieres, ve a redwoodjs.com y regístrate para obtener algunas pegatinas gratis. Gracias por escuchar.

¿Qué te parecen estas respuestas aquí? ¿Es esto lo que esperabas o? Bueno, veamos. Esperaba que mucha gente no hubiera oído hablar de Redwood para que ahora pudieran haber oído hablar de él y responder que lo habían hecho en el futuro. Así que veamos, nunca había oído hablar de él. Sí, el 30%. Oí hablar de él, pero nunca lo probé. Eso es realmente asombroso. Me gusta seguir la pista de cuánto Redwood está en la conciencia pública, ¿estamos difundiendo la palabra? Y entonces, esto es genial, esto es en realidad, pensé que podría ser más bajo que esto, pero esto es asombroso. Quiero decir, como, oír hablar de ello es el primer bit. Lo probé o lo usé en un proyecto, 0%. Bueno, no hay más que subir desde allí. Somos un proyecto joven, así que creo que esto es, quiero decir, esto es exactamente donde queremos estar cuando se trata de estas cosas.

Queremos estar donde la gente ha oído hablar de él, y ahora pueden pasar al siguiente paso. Exactamente, creo que estas son buenas estadísticas. Algunos de ellos nunca han oído hablar de él, así que ahora lo han hecho, y ahora pueden probarlo y seguir desde allí seguro. Exactamente, exactamente.

Sí, vamos a la audiencia con algunas preguntas y respuestas, y recordaré, audiencia, si tienen alguna pregunta para Tom, adelante y colóquenlas en el Andromeda Q&A en Discord, y las responderemos ahora mismo. Ya tenemos un par de preguntas aquí para ti, Tom.

La primera es, ¿Redwood es de código abierto? Sí, Redwood tiene licencia MIT y es gratuito para usar, así que el cielo es el límite. Úsalo para lo que quieras. Hazlo tuyo, cámbialo. Nos encantan las contribuciones, obviamente. Tenemos más de 250 personas que han contribuido al framework ya. De hecho, hemos estado trabajando en él durante varios años, por lo que se ha vuelto bastante maduro, pero aún está pre 1.0. Aunque un 1.0 llegará muy pronto. Estamos en la fase de candidato a lanzamiento ahora, y por eso nos encantan las contribuciones. Por eso es de código abierto. Soy un gran defensor del código abierto. Me ha ayudado mucho en mi carrera, y siempre he disfrutado participando en el código abierto, así que absolutamente, licencia MIT, gratuito para usar.

Genial, sí, también me encanta el código abierto. ¿Qué pasa con la capacidad de producción? ¿Está listo para uso en producción? Bueno, no es del todo 1.0. Como dije, estamos en la fase de candidato a lanzamiento ahora. Acabamos de entrar en eso hace una semana y media, y por lo tanto es bastante estable. Todavía hay algunas correcciones de errores que haremos. Tenemos la intención de estar en la fase de candidato a lanzamiento probablemente hasta febrero o marzo del próximo año, así que un par de meses mientras trabajamos en los errores y nos aseguramos de que la primera experiencia del usuario sea realmente de primera categoría. Tenemos un increíble tutorial que si estás interesado en lo que viste hoy, ve a redwoodjs.com y repasa un poco el tutorial, y aprenderás mucho más no solo sobre el backend, sino también sobre el frontend ya que Redwood es una pila completa marco de aplicación web. No es solo el lado GraphQL que viste hoy. Realmente tiene un lado de aplicación web completa también, y por eso trabajamos muy duro en eso, y deberíamos ser 1.0 en un par de meses, lo que significa que diría absolutamente, sí, úsalo en producción. Aunque hay startups, startups financiadas hoy están construyendo con Redwood y en producción, por lo que se puede hacer.

Increíble, genial. Bueno, hablando de eso, como mostraste un montón de cosas realmente geniales. Hiciste que pareciera tan fácil en el backend.

¿Y qué pasa con el frontend? ¿Cómo es y cuáles son sus fortalezas con el frontend? En este momento, Redwood tiene un frontend basado en React, y hacemos mucho trabajo para integrar el frontend y el backend. Así que tenemos una característica que llamamos celdas, que es una forma declarativa de hacer la obtención de data. Entonces, una vez que tienes tu backend GraphQL en el frontend, si quieres hacer la obtención de data para obtener data y luego renderizar un componente React, usa lo que se llama una celda, y simplemente dices cuál es tu consulta, y luego dices qué quieres que suceda, qué componente quieres que se renderice cuando estás en un estado de carga, cuando estás en un estado de fallo, cuando tienes un conjunto de resultados vacío devuelto, o cuando tienes un retorno exitoso, simplemente enumeras cuáles serían esos componentes, en lugar de tener todo tipo de condicionales por los que tienes que pasar en tu base de code, lo que facilita mucho la gestión, y nos permite entrar en el ciclo de vida para que en el futuro, podamos hacer cosas aún más interesantes y optimizar ese flujo de obtención de data, pero eso es solo una de las muchas cosas que hacemos.

Tenemos capacidades de pre-renderizado, así que en tu archivo de rutas, puedes simplemente decir que quieres que una página específica sea pre-renderizada y luego en el momento de la construcción, pre-renderizaremos esa página para que esté disponible estáticamente, lo cual es genial para el SEO y el performance, y luego será hidratada en el cliente y presentada al usuario. Y estas son solo algunas de las características que tenemos. Obviamente puedes ir al sitio web y ver todo lo que hay allí. El tutorial cubre todo esto muy bien. Así que si estás intrigado, definitivamente pasa por el tutorial. Eso es lo primero que debes hacer si quieres aprender más.

Sí, suena muy interesante y parece que resuelve muchos problemas que otros frameworks podrían tener o que están tratando de resolver también. Y hablando de eso, ¿cómo se compara Redwood con otros frameworks de pila completa? Y Metin específicamente quiere saber, ¿hay alguno que te asuste? Así que vivimos en el mismo espacio que supongo, Next.js, obviamente muy popular, es increíble. Es un pequeño framework asombroso. Ahora no aporta mucho más a la mesa. Como hay muchas cosas que funcionan con él, pero vas a hacer la mayor parte del trabajo tú mismo para integrar esas cosas. Y así, comparado con Next, Redwood integra un gran conjunto de herramientas, Storybook está incluido por defecto, no tienes que configurarlo, está totalmente integrado. Jest, pruebas, integrado. GraphQL en el backend, integrado. Todas estas herramientas que eventualmente querrás añadir si estás construyendo un proyecto o una startup ya están ahí con Redwood. Así que esa es la mayor diferencia cuando se trata de algo como Next. Ahora hay otros frameworks que también se están construyendo hoy en día como de pila completa. Cosas como Blitz.js, que se construye encima de Next, añade capacidades de backend de pila completa. También integran Prisma desde el lado de la base de datos, pero está construido en un contexto más de Next. Así que si te gusta Next, ese es uno a tener en cuenta. Y luego también está Remix, que recientemente ha sido de código abierto y está tomando una postura un poco diferente allí. Ahora, ninguno de estos otros dos está aprovechando GraphQL. Así que si estás viendo esta conferencia, supongo que te gusta GraphQL. Y así, si quieres usar GraphQL como tu protocolo de transporte desde tu frontend hasta tu backend y facilitar la adición de clientes adicionales a medida que avanzas, un cliente móvil o un cliente de línea de comandos o lo que sea, entonces Redwood va a estar súper optimizado exactamente para ese caso. Y una gran razón para elegir Redwood será por GraphQL, que ninguno de los competidores te ofrecerá.

Genial. Entonces mencionaste que el front-end usa, o dijiste que ahora el front-end usa reactivo, ¿hay planes de quizás cambiar eso a algo más o tal vez incorporar otros front-ends como un tipo de Astro? Sí, desde el principio, hemos pretendido que Redwood sea un tipo de arquitectura multi-cliente, por eso usamos GraphQL. Una de las cosas que podemos hacer en el futuro debido a eso es agregar muy fácilmente otras tecnologías de renderizado de clientes. Así que podrías imaginar que además de un sitio web front-end basado en React, podríamos tener un sitio web front-end basado en Vue o Svelte que todavía solo consume el mismo back-end GraphQL e incluso podrías usar varios de esos si tuvieras diferentes sitios que quisieras implementar usando diferentes tecnologías front-end a lo largo de los años o realmente no es diferente que tener un React basado, como una aplicación móvil React Native que nos encantaría agregar en algún momento y una vez que lleguemos a 1.0, comenzaremos a investigar en qué otras tecnologías la gente está interesada en que trabajemos y hagamos que esas cosas sean mucho más fáciles de integrar con tu back-end GraphQL también. Así que el cielo es el límite cuando se trata de tecnologías front-end. Sí, no, eso es increíble. Tener tantas opciones diferentes, a la gente le encanta tener las opciones. Así que hay una pregunta más aquí de vuelta al tema del código abierto, ¿hay un plan para un modelo de ganancias ya que es de código abierto? ¿Cómo vas a financiarlo? Bueno, ahora mismo lo financio yo mismo y hay un número de personas trabajando en ello a tiempo completo. Me encuentro en la afortunada posición de poder hacerlo y me gusta eso porque no tengo que preocuparme de ninguna de las cosas de startup que normalmente vienen con esto. No tengo que preocuparme por los VCs tratando de hacer que las cosas vayan más rápido de lo que deberían, o aprovechar y monetizar cosas que son un poco antinaturales. Es difícil decir qué le depara el futuro a Redwood. Principalmente quería que esto existiera para ayudar a las personas a construir sus startups y proyectos más rápidamente. Por eso estoy en este espacio para empezar. Por eso me convertí en desarrollador yo mismo. Y así, poder devolver de esta manera es realmente satisfactorio para mí. Ahora me encantaría que hubiera algún tipo de membresía de Redwood algún día donde la gente pudiera pagar alguna tarifa para tener acceso al equipo más fácilmente o a contenido premium o algo así para que no tenga que pagar la factura completamente yo mismo para siempre, lo cual sería agradable, pero siempre quiero que se haga de una manera que sea aditiva y de una manera que realmente abrace a la comunidad y empuje a Redwood hacia adelante desde una perspectiva de código abierto y realmente se haga para el beneficio de la comunidad. Eso es realmente importante para mí. Esa es la verdadera naturaleza del código abierto. Eso es increíble. Te felicito por hacer eso. Eso es genial. Así que esas son todas las preguntas que tenemos de la audiencia. Así que quiero agradecerte, Tom. Y vamos a invitar a cualquiera que tenga más preguntas a ir al chat espacial a la sala de conferencias de Tom. Puedes hacer más preguntas allí. Pero por ahora, voy a decir gracias de nuevo, Tom, y luego vamos a pasar a nuestro próximo tema. Muchas gracias. Muy bien.