Aplicaciones sólidas de React y GraphQL para personas con prisa

Bueno, definitivamente ha pasado un tiempo desde que comencé a trabajar con GraphQL. De hecho, han pasado unos 5 años, y en años tecnológicos eso es bastante tiempo. Y cuando comencé a trabajar con GraphQL al principio, realmente no me importaba cuánto tiempo llevaría trabajar en un proyecto o poner en marcha una aplicación de GraphQL. Pero en estos días cada vez más me encuentro con prisa en mis proyectos y quiero algo que sea más rápido para comenzar y más rápido de mantener. Y eso es de lo que voy a hablar hoy, cómo lidiar con React específicamente y GraphQL si tienes prisa.

Me llamo Ryan y hago muchas cosas en la web. Pero hoy estoy muy enfocado en Course Lifts y Course Lift es un alojamiento de cursos para personas que quieren tener todas las mecánicas de cómo armar sus páginas de inicio de curso, cómo armar su información de ventas, etc. Hecho para ellos para que puedan centrarse en hacer su curso y nosotros les ayudamos a vender su curso. Échale un vistazo a Course Lift en Twitter si estás interesado.

Volviendo a 2017, hace cinco años, cuando empecé a involucrarme con GraphQL, fue un momento increíble porque había tanta energía en la comunidad en torno a GraphQL. Era bastante nuevo. Creo que se remonta a 2012 en su inicio, pero fue alrededor de esta época en 2017 que la gente comenzó a emocionarse mucho con él y esa emoción era realmente palpable. Esta soy yo en la Cumbre de GraphQL en San Francisco. Tuve la oportunidad de dar una charla allí en 2017 y había mucha energía en la sala sobre GraphQL. La gente quería usarlo en todas partes. La gente quería usarlo en todas sus APIs, desde todos sus frontends, y realmente podías sentir eso en la conferencia. Fue alrededor de esta época que comencé a trabajar en un proyecto grande para un cliente nuevo. En ese momento estaba trabajando para Auth0, pero comencé a independizarme y a hacer trabajos de consultoría y empecé a trabajar en proyectos grandes que utilizaban GraphQL en este nuevo caso de este nuevo proyecto. Fue alrededor de este momento que realmente empecé a familiarizarme con GraphQL. Estaba tratando de averiguar cómo incorporarlo a este proyecto y cómo hacerlo realmente bueno para el cliente en particular. Lo que noté es que había muchas frustraciones que surgieron cuando comencé a trabajar en este proyecto. Podría agruparlas en algunas categorías diferentes. La primera es que en ese momento no estaba muy claro cómo lidiar con diferentes módulos, cómo separar partes de la API en diferentes secciones, cómo lidiar con cosas como, ok, quiero un módulo de usuarios y luego quiero tener un módulo para algún otro recurso. Cómo agrupar esas cosas y luego unirlas de manera cohesiva simplemente no estaba establecido claramente. Y así, debido a que no había estas convenciones establecidas, uno quedaba para resolver esas cosas por su cuenta. Y así, encontré una convención que funcionaba en mi proyecto, pero definitivamente era bastante personalizada y tal vez no era la mejor manera de hacer las cosas. Esto llevó, creo, a mucho trabajo repetitivo y manual. Estaba copiando y pegando carpetas de módulos, cambiando nombres y luego teniendo que importar cosas en un archivo principal. Poner todas esas cosas en un esquema ejecutable en Node. Y era solo esta tarea repetitiva y manual con la que tenía que lidiar.

Y en ese momento, tampoco existían realmente buenas abstracciones frontend para la integración en tiempo de desarrollo frontend-backend. Recuerdo que no estaba del todo claro cómo obtener información cuando estás trabajando en el frontend sobre lo que el backend podía ofrecer en términos de recursos o campos en tus recursos. Y así, esta integración entre los clientes de consulta frontend y el esquema backend, simplemente no estaba bien establecida en ese momento sobre cómo hacer que esas cosas funcionen bien juntas. Esto llevó realmente a un conjunto de soluciones personalizadas y frágiles. Junté cosas que pensé que funcionaban bien en la aplicación y resultó que eran un poco frágiles. Cosas como problemas al agregar nuevos módulos, olvidar importar una de las nuevas partes del esquema en mi archivo principal donde creo el esquema ejecutable. Cosas como tener que lidiar con la carga de archivos y la autenticación. Todas estas diferentes partes de la aplicación que son bastante estándar en la mayoría de los lugares, simplemente no eran tan estándar en GraphQL en ese momento.

Las cosas definitivamente han mejorado a lo largo de los años. La adopción ha crecido. Cada vez más empresas grandes están utilizando GraphQL y más desarrolladores en todas partes lo están probando. Creo que casi todos los puntos técnicos de GraphQL han mejorado a lo largo de los años. Ahora tenemos mejores bibliotecas de servidor. De hecho, tenemos más de ellas. Tenemos mejores formas de organizar estas convenciones en nuestros proyectos. Las herramientas son mejores en general. Tenemos integraciones desde editores de código y tenemos integraciones entre frontends y backends en tiempo de desarrollo, lo cual es genial. Tenemos cosas como la generación de código, que ayuda a realizar modificaciones en nuestro código de una manera fácil. Y en última instancia, la seguridad de tipos realmente ha sido un gran beneficio de todo esto. Poder conocer los tipos que están disponibles en la API de GraphQL y luego poder utilizarlos en toda la pila de la aplicación ha sido realmente beneficioso para la seguridad de tipos en tiempo de desarrollo.

Pero creo que aún hay margen de mejora y eso se debe a que los nuevos desarrolladores de GraphQL a menudo quedan confundidos. He hablado con muchos desarrolladores de GraphQL que tienen dificultades para comprender todas las piezas en juego cuando intentan comenzar. Y creo que esto se debe a que el ciclo de aprendizaje de GraphQL puede ser bastante desafiante. Tener que entender qué es un esquema, qué es un resolvedor y cómo interactuar con esas dos cosas desde el cliente puede ser un poco desafiante. La pregunta de dónde encaja GraphQL en el stack también puede ser desafiante. Algunas personas piensan que se debe colocar GraphQL entre el servidor y la base de datos, por ejemplo, mientras que otros piensan que es estrictamente entre el cliente y el servidor. Por lo tanto, informar a los nuevos desarrolladores sobre dónde realmente debe encajar GraphQL en su stack puede ser un desafío.

¿Cómo se trabaja con otras APIs cuando se utiliza GraphQL? ¿Cómo se trabaja con APIs que no están construidas en GraphQL e integrarlas? Y luego, ¿qué herramientas son necesarias para que todo el stack encaje? Y eso también puede ser un desafío para los nuevos desarrolladores. Por lo tanto, creo que si podemos obtener éxitos tempranos, éxitos tempranos en el sentido de poder comprender los claros beneficios de GraphQL de una manera rápida, creo que es posible entusiasmar más a los desarrolladores con GraphQL. Y si queremos que haya más adopción de GraphQL, si queremos que más personas lo prueben y lo utilicen en sus proyectos, creo que centrarse en esos éxitos tempranos es una parte fundamental de ello.

En mi opinión, hay una experiencia ideal y se ve así. Deberíamos poder ver fácilmente desde el principio los beneficios claros de esa relación cliente-servidor sin tener que pensar en todos los detalles técnicos. Sin tener que pensar en, bueno, ¿cuál es exactamente la definición de un esquema? ¿Qué significa un resolvedor? ¿Qué es la parte del cliente? ¿De qué se trata todo esto? En cambio, poder mostrar el contrato claro que existe entre esas cosas y poder hacerlo de una manera en la que el desarrollador no necesite pensar en todos los detalles y los aspectos técnicos, creo que es una gran ventaja. Tener una forma de manejar otras piezas que se encuentran en cualquier otro tipo de entorno, creo que también es importante. Cosas como la autenticación y la autorización, la carga de archivos, esas cosas que son necesidades en las aplicaciones. Creo que poder demostrar cómo hacer esas cosas de manera fácil y temprana es una parte importante. Y luego, estar automáticamente informado sobre el esquema de GraphQL en todo el stack. Obtener información de tipo del esquema de GraphQL que existe, poder utilizar esa información de tipo para informarnos en tiempo de desarrollo y tener una forma fácil de hacerlo, creo que es clave. Hay numerosas formas en que esto se hace más fácil en la actualidad. Hay cada vez más frameworks, cada vez más paquetes para comenzar que ayudan con este tipo de cosas. Pero el que hablaré hoy y el que creo que es probablemente la mejor forma de dar vida a esta experiencia es un framework más nuevo llamado RedwoodJS. RedwoodJS es un framework altamente opinado. Reúne muchas piezas diferentes de tecnología de una manera muy cohesiva y muy agradable de usar. Y una de las cosas que me encanta es que ofrece muchas convenciones y patrones que facilitan mucho mantener la consistencia en una aplicación, especialmente si se trabaja con varios desarrolladores. Y es un framework muy bueno que reúne muchas tecnologías excelentes de las que hablaremos hoy.

¿Cómo se ve una aplicación de Redwood? Bueno, reúne estos elementos. Tenemos React, GraphQL, Node, Prisma, Storybook y Jest. Esas son las piezas principales. También hay algunas otras. Y reúne estas tecnologías de una manera que es súper cohesiva y súper fácil de comenzar y seguir adelante.

No tenemos que preocuparnos demasiado por estas piezas. Sabes, a medida que nuestra aplicación crece, simplemente siguen funcionando y funcionan muy bien.

Cuando se trata de una aplicación de Redwood, tenemos dos lados. Las aplicaciones de Redwood existen en un repositorio único, en un espacio de trabajo de Yarn. Tenemos un lado web y un lado API. Y este enfoque de repositorio único es genial porque nos permite trabajar dentro de un solo proyecto, pero trabajar en ambos lados, el lado web y el lado API.

Y así, la pregunta a menudo es sobre Redwood, ¿qué hace? ¿Simplemente instala un montón de paquetes para nosotros, para esas tecnologías? ¿Simplemente nos da un archivo package JSON y luego instalamos todas esas piezas individuales de tecnología? Y la respuesta es no, hace mucho más que eso. Nos brinda un conjunto enorme de generadores, que ahorra mucho tiempo en la generación de código. Obtenemos andamiaje para cosas como poder tomar un modelo y luego poder darnos toda la funcionalidad CRUD relacionada con él. Así que todas las piezas de esquema que necesitamos, resolvedores que necesitamos. Y también todas las partes del frontend que necesitamos, para poder hacer CRUD. Obtenemos autenticación lista para usar. Así que, típicamente, si estás trabajando con autenticación en GraphQL, es posible que estés buscando una directiva personalizada. Obtenemos todas esas cosas automáticamente con Redwood. Obtenemos el enrutamiento resuelto con Redwood. Obtenemos una implementación muy buena de un enrutador dentro de la capa de React con Redwood. Es una abstracción muy inteligente, funciona muy bien. Obtenemos cosas como diseños, ya sabes, una convención para tener una estructura de aplicación, por ejemplo, que se puede utilizar en toda la aplicación. Obtenemos modificaciones de código. Cuando llega el momento de actualizar la versión de Redwood en la que te encuentras, a menudo hay código que necesita ser actualizado en toda la aplicación, y podemos ejecutar un simple comando NPX para actualizar ese código en toda la aplicación, lo cual es genial. Trabajamos dentro de monorepos. Hace las cosas mucho más simples cuando estamos tratando con un solo repositorio para el frontend y el backend de nuestro stack de aplicación, en lugar de tener múltiples piezas de las que tenemos que preocuparnos y que se despliegan de diferentes formas, etc. Y luego, lo que más me gusta son los patrones personalizados que ofrece Redwood, cosas como cells, de las que hablaremos más adelante. Cells son esta abstracción que nos brinda una forma de manejar todo el ciclo de vida de una operación CRUD. Y veremos eso con más detalle. Generar componentes es muy sencillo. Usamos un comando yarn, por lo que es yarn Redwood generate components y el nombre de tu componente, por ejemplo. Obtenemos lo mismo con una página. Tendríamos un componente que podría ser solo una parte aislada de una interfaz de usuario en la que podríamos estar trabajando. También podríamos querer tener una página, que es como una estructura más grande donde van nuestros componentes.

Y luego, también podríamos querer generar un diseño, que sería una especie de una estructura de aplicación. Puedes pensarlo así, que en última instancia ofrece algo que se ve así, teniendo nuestra estructura de aplicación con cualquier número de páginas que pueda haber en ella.

Y luego esas páginas en sí mismas implementarían varios componentes. Y esta es una forma bastante típica en que se organiza una aplicación. Tienes, por ejemplo, una barra de navegación y una barra lateral en tu diseño, luego tienes páginas dentro de las cuales se puede navegar y luego componentes que realizan el trabajo de la aplicación.

Luego, si estamos tratando con, ya sabes, un recurso del servidor, algo que residiría como una parte del esquema en nuestro servidor con un resolvedor, podemos generar un SDL. Entonces sería yarn, red generaría un SDL, dándole un nombre. Y luego obtendríamos un esquema completo de GraphQL, un conjunto completo de resolvedores y podríamos usarlo de inmediato con llamadas a GraphQL.

Así que eso es gran parte de la teoría. ¿Por qué no vemos Redwood JS en acción y podemos ver cómo GraphQL realmente brilla dentro de una aplicación Redwood. Entonces, cuando estamos trabajando con Redwood y queremos comenzar un nuevo proyecto, podemos hacerlo con Yarn. Podemos hacer Yarn create Redwood app y luego darle un nombre a la aplicación. Llamémosla GraphQL Galaxy. Y luego voy a decir que quiero TypeScript. Típicamente esto es lo que siempre hago. Sabes, TypeScript es lo que uso por defecto, pero también puedes obtener Redwood en una versión estándar de JS si lo deseas. Solo no agregues el guión guión TypeScript al final.

Cuando hacemos eso, vamos a obtener una nueva aplicación iniciada para nosotros. Va a instalar todo tipo de dependencias. Va a recopilar todos los paquetes que están dentro de una aplicación Redwood aplicación. Así que React, GraphQL, tenemos Storybook, Jest y más. Y va a juntar todas esas cosas para nosotros en nuestro nuevo paquete. Va a ejecutar Yarn install y va a generar los tipos de inmediato. La generación de tipos es algo que sucede automáticamente dentro de Redwood JS, y eso también va a suceder aquí en la fase de instalación. Así que vamos a darle un minuto para que se ejecute, y luego vamos a entrar en el proyecto y ver cómo trabajar con GraphQL en él.

Muy bien, ya estamos listos aquí. Así que voy a entrar en GraphQL Galaxy, y vamos a abrir esto en VS Code. Y vamos a hacer un recorrido rápido aquí de lo que hay en los directorios. Como mencioné, tenemos dos lados. Tenemos un lado del sitio web y un lado de la API.

Aquí está nuestro sitio web, todo lo que se incluye en la parte del cliente de nuestra aplicación. Luego está el lado de la API, y aquí es donde se encuentran cosas como nuestros modelos de database con Prisma, y también es donde vamos a gestionar nuestras piezas de GraphQL. Lo primero que podríamos hacer es ejecutar esto y ver cómo se ve en el navegador. Para eso, podemos hacer Yarn redwood, o si queremos, abreviarlo, rwdev. Y cuando lo hagamos, tendremos un nuevo proyecto en el navegador que podemos ver.

Esta es la página principal de Redwood. Todavía no tenemos nada en términos de páginas, pero podemos generar una y hagámoslo ahora mismo. Generemos una página. Para hacer eso, abriré una nueva terminal y haré Yarn redwood, o simplemente rw para abreviar. Generar una página y llamémosla página de galaxy. Y veremos cómo se ve esto en el navegador. Cuando generamos la página, se guarda en el directorio web, si vamos a Source, a Pages, ahí está nuestra página de galaxy, y tiene cosas en las que estamos interesados, como nuestro componente de React que forma la página y también una prueba que viene de forma gratuita, y una historia de Storybook en la que también podemos trabajar.

Aquí, nuestra página está apareciendo, vamos a navegar a ella. Aquí está nuestra página de galaxy. Entonces, para esta página, tal vez queramos tener un recurso galaxy en nuestro backend con el que podamos trabajar, algo en nuestra database, un recurso con el que podamos realizar algunas operaciones CRUD en contra. Con eso, volvamos aquí, de vuelta a la terminal, y ahora vamos a usar algo llamado un scaffold. Pero lo primero que tenemos que hacer es configurar nuestro modelo. Vamos al directorio API, y vamos a nuestro modelo, que estará en DB, schema.prisma, y lo que haremos es eliminar este ejemplo que viene con la instalación de Redwood, y nos daremos un nuevo modelo llamado galaxy. Esto será como una tabla que contendrá galaxias. Así que tal vez la Vía Láctea, Andrómeda y todas las demás que existen en el vasto universo. Comencemos teniendo un campo de id aquí. Por ahora, lo haremos un entero, y el valor predeterminado puede ser autoincremental, así que autoincrementaremos ese id. Querremos decir que este es también el id para esta tabla en particular. Podríamos querer un nombre. El nombre puede ser una cadena. Podríamos querer una descripción, que también será una cadena. Y típicamente queremos llevar un registro de cuándo se creó un recurso. Así que created at puede ser un campo. Eso es de tipo datetime, y el valor predeterminado puede ser ahora. Y tal vez también pueda haber un updated at, y podemos rastrear cuándo ocurren las actualizaciones.

Ese es un campo de fecha y hora, y podemos usar el decorador updated at para obtener automáticamente esos valores. Así que tenemos una tabla de galaxias, y estamos usando, en este caso, SQLite como nuestra base de datos. Si ejecutamos la instalación en esto, deberíamos obtener todo conectado.

Entonces, digamos que si ejecutamos nuestro generador para esto, deberíamos obtener todo conectado. Así que podemos hacer yarn redwood prisma db push, eso debería darnos nuestra base de datos. Así que ahí está nuestra base de datos, dev.db, y ahora tendrá esa tabla de galaxias en su lugar. Y lo que podemos hacer para facilitarnos mucho el trabajo con los datos aquí es hacer yarn redwood scaffold, o generar, scaffold galaxy. Ejecutemos ese comando y veremos qué obtenemos.

Así que tenemos un diseño. Tenemos rutas. Tenemos todo tipo de cosas. Si vamos a nuestro archivo de rutas, este es nuestro archivo de enrutamiento a nivel de React. Tenemos un montón de rutas nuevas. Tenemos una ruta donde podemos agregar una nueva galaxia, tenemos una ruta donde podemos editar una existente, y todo tipo de cosas que apuntan a diferentes componentes que se han creado para nosotros. Si echamos un vistazo dentro de nuestro directorio web. Así que tenemos una nueva página aquí que es una página de galaxia. Creé una página inicial llamada galaxia, que probablemente podríamos eliminar ahora, ya que tenemos otra página dedicada llamada página de galaxia. Tenemos un conjunto de componentes que se ajustan a este recurso de galaxia, lo que nos permitirá hacer todo lo que queremos hacer para administrar CRUD.

Si miramos en el directorio API, también tenemos un montón de cosas. Por ejemplo, galaxies.sdl. Este es el esquema GraphQL en el servidor que queremos para administrar este recurso. Podemos ver que de inmediato nos da lo que podríamos esperar en función de una muestra inicial de este modelo que está en la base de datos. Tomando los campos que están en este modelo, podemos inferir que podríamos querer tener ID, nombre, descripción, todas estas cosas disponibles como parámetros en este objeto. Obtenemos consultas para galaxias, en plural, una sola galaxia por su ID. Tenemos la capacidad de hacer mutaciones de inmediato. Y si te fijas aquí, estamos requiriendo autenticación de inmediato. Tenemos este decorador require auth. Si no queremos eso, podemos optar por omitir la autenticación, lo cual es útil durante el desarrollo. Pero es una característica muy agradable de Redwood que automáticamente nos brindará autenticación para proteger nuestros recursos en caso de que nos olvidemos, por ejemplo. Así que tenemos todo en su lugar aquí para tener un conjunto completo de operaciones CRUD.

Si miramos en el directorio de servicios aquí en galaxies.ts, estos son los resolutores acompañantes que se utilizarán para realizar todas estas operaciones CRUD. Entonces, ¿por qué no echamos un vistazo de nuevo en el navegador? Si actualizamos, no hay nada en la página aquí. Y eso se debe a que necesitamos llegar a un punto donde podamos editarlo. Así que si vamos a galaxies/nuevo, aquí vamos, podemos agregar una nueva galaxia. En la Vía Láctea hogar. Llamémosle hogar como descripción. Guardaremos esto. Ahí está el registro en nuestra database. Podemos editarlo para que sea algo más. Podemos guardar eso. Podemos eliminarlo. Podemos mostrarlo. Tenemos todo tipo de operaciones que nos son proporcionadas de forma gratuita por Redwood mediante la generación de este scaffold.

La parte importante en la que me enfocaré aquí es que todas las partes de GraphQL se resuelven automáticamente al ejecutar ese comando. Por ejemplo, si vamos al directorio de componentes a Galaxy y luego vamos a Galaxy cell, aquí está nuestra consulta GraphQL que se generó. Solicita todos los campos que tenemos en ese modelo. Configura todos los estados en los que podríamos estar para realizar una operación CRUD. ¿Qué sucede si hay una operación exitosa? Nos prepara para eso. ¿Qué sucede si estamos en un estado de carga? ¿Qué sucede si estamos vacíos o si hay una falla? También nos los proporciona. Y las piezas del servidor correspondientes a esto, como ya hemos visto, ya están allí, generadas automáticamente.

Entonces, cuando pensamos en una forma para que los desarrolladores comiencen con GraphQL de una manera muy sencilla, una forma muy fácil donde puedan ver los beneficios de GraphQL en sí mismo, creo que Redwood proporciona un camino muy claro para eso. Las cosas se generan automáticamente. No necesitamos perder tiempo descubriendo exactamente la sintaxis de la pieza SDL que podríamos necesitar, cómo vincular un resolver a ella, cómo colocar la pieza de consulta. Simplemente se hace automáticamente por nosotros. Y luego podemos dedicar tiempo a comprender cómo funcionan todas estas piezas juntas. Pero esa forma muy fácil de comenzar se hace por nosotros, lo cual creo que es una gran ventaja.

Entonces, si eres nuevo en GraphQL y te gusta lo que has visto en términos de un camino claro para comenzar, visita RedwoodJS.com y es tan fácil como lo mostramos hoy. O si eres un desarrollador experimentado de GraphQL y alguien que conoces está interesado en GraphQL, te recomendaría que les hables sobre Redwood para que puedan tener esa experiencia de comenzar muy fácil. Quita los aspectos mecánicos del camino, obtén un camino muy claro para obtener el beneficio primero y luego descubre el resto después. Muchas gracias. Mi nombre es Ryan y una vez más soy el fundador de Courselift. Si estás interesado en alojamiento de cursos que te ayuda a comercializar y vender tus cursos, visita Courselift.com o Courselift en Twitter. Muchas gracias.

Hola Ryan, bienvenido. Muchas gracias por estar aquí. Solo un recordatorio para los asistentes, pueden hacer sus preguntas a Ryan en Discord y en el canal de preguntas y respuestas de Andrew Meda. Entonces sí, Ryan, adelante y comencemos echando un vistazo a los resultados de la encuesta que hiciste antes de tu charla. Suena bien. Nuevamente en Slido, podemos echar un vistazo y ver. Parece que la mayoría de las personas han respondido, alrededor del 50% ha respondido generar modelo de esquema. Closely behind is generate SDL model. Entonces, ¿qué opinas sobre esas respuestas? Creo que las personas estaban en el camino correcto, pero parece que la correcta fue votada menos que la incorrecta. Es SDL, para obtener un conjunto completo de resolutores CRUD, de tu SDL para tu backend. Entonces, si tienes algún modelo en tu esquema de PRISMA, puedes hacer yarn redwood generate SDL, y luego el nombre de tu modelo, y luego obtienes todo ese código generado para ti.

¡Increíble! Sí, suena como una forma realmente genial de comenzar y darte todo lo que necesitas. Así que genial. Increíble.

Bueno, vamos a comenzar con algunas de las preguntas que estamos viendo. La primera es, ¿cómo se diferencia Redwood de otros frameworks y meta frameworks, cosas como next o blitz, etc.?

Sí, Redwood es un concepto interesante. Reúne varias piezas de tecnología que ya están establecidas y son bien conocidas. Como vimos en la charla, incluye React, GraphQL, Jest, Storybook, entre otros. Los reúne y te brinda una forma coherente de usarlos sin mucho problema, ¿verdad? Pero una de las partes más difíciles, creo, al comenzar un proyecto en el que quieres usar todas esas piezas de tecnología, es tener que conectarlas todas y seguir la documentación para hacerlo. Redwood simplemente resuelve eso por ti.

Diría que, por ejemplo, Next.js se centra mucho más en React. Por supuesto, puedes hacer cosas de API con Next, pero Next no tiene una opinión tan clara sobre cómo integrar GraphQL, por ejemplo. Redwood te ofrece una forma de tener un frontend y un backend, pero es menos dogmático en ese sentido. Aunque sigue siendo dogmático en el hecho de que te brinda su propia forma específica de usar React y un backend, pero con menos herramientas.

Diría que Redwood está más estrechamente relacionado con algo como Blitz. Blitz tiene objetivos similares, te brinda comandos para crear una aplicación desde cero para ti. Te brinda una forma de vincular fácilmente varias piezas. Entonces, Redwood es similar en ese sentido a Blitz, pero con sus propias opiniones, etc. Y si miras otros frameworks, quiero decir, si, quiero decir, tal vez consideres a React en sí mismo un framework, algunos dirían que sí, otros dicen que es solo una biblioteca. Pero difiere en ese sentido porque React es solo para la interfaz de usuario en su mayor parte. Y luego, ya sabes, lo mismo con frameworks como Angular, por ejemplo. Verías más a Redwood haciendo todo en el stack completo por ti. Mientras que Angular solo se enfoca en el frontend. Así que creo que eso es un poco de cómo difieren.

Sí, es interesante. Creo que si miras frameworks, bibliotecas, ya sabes, utilidades, como APIs, y piensas en algunos aspectos como, ¿es esto frontend, backend, stack completo? ¿Es esto dogmático versus no dogmático? ¿Es esto más una biblioteca versus un framework donde va a ser muy directivo en cómo lo usas? Sí. Así que creo que parece haber una superposición interesante en esos tres aspectos. Si quieres comenzar rápidamente, cubrir la mayor parte del stack posible. Y también tener pautas establecidas para poder tomar decisiones que estén en línea con las mejores prácticas.

Cubre muchos de esos casos de uso, por así decirlo. Sin duda. Y, y una cosa que fue importante para Redwood desde el principio, es que esté dirigido a Facilitar la implementación, en un sentido de JAMstack, por lo que la implementación en serverless. Donde, sin ningún problema en absoluto, implementarías tus puntos finales de GraphQL en una función serverless. También podrías implementar cualquier tipo de funciones individuales con las que quieras trabajar como funciones serverless. Así que es muy fácil trabajar con serverless también. Sí, y estamos viendo que desde un punto de vista arquitectónico, los equipos que pueden trabajar en ese entorno, pueden moverse bastante rápido, lo cual es genial. Así que es increíble.

Otra pregunta está relacionada con eso, de hecho. ¿Qué características de Redwood ofrecen las mayores ganancias de productividad? Sí, para mí son los generadores. Esos son bastante grandes. Sabes, hay un argumento que se puede hacer de que los generadores pueden no ser lo más importante para un framework porque una vez que has generado tu código, luego estás manteniendo los componentes que ya has construido. Y tal vez no siempre estás usando generadores. Pero para mí, especialmente al comenzar un proyecto, poder crear cosas y generar, obtener una gran cantidad de código ya hecho es enorme. Y he comenzado a usar, me subí al tren con ChatGBT dándome código ahora. Estoy usando Copilot y cosas así. Así que cuanto más código pueda ser escrito por mí, mejor. No soy un purista que dice que tengo que escribir todo mi propio código. Con gusto dejaré que la computadora escriba el código por mí. Así que Redwood es genial para eso, ya sabes, generar código para que puedas salir por la puerta. Y luego haces los cambios apropiados que necesitas, por supuesto, en tus componentes y construyes a partir de ahí. Así que es un impulso enorme. Increíble.

Y una última pregunta para la que tenemos tiempo. ¿Hay alguna característica que esté por venir y que esperes con ansias? Bueno, ahora se está hablando de manejar la autenticación de una manera un poco diferente. Hasta ahora, el modelo de autenticación de Redwood ha estado estrictamente vinculado a un proveedor. Puedes usar muchos proveedores diferentes, pero está bastante acoplado a ese proveedor que elijas. Y ahora hay trabajo por hacer para desacoplar la autenticación que tradicionalmente ha estado acoplada a un proveedor específico. Así que estoy deseando eso. Increíble. Bueno, no puedo esperar para aprender más al respecto. Y muchas gracias, Ryan, por responder nuestras preguntas y por tu increíble charla. Realmente apreciamos que estés aquí. Absolutamente. Feliz de estar aquí. Gracias.