Log in
GraphQL Galaxy 2020GraphQL Galaxy 2020
talks

Construye tus APIs de GraphQL más rápido con Nexus Schema

Ryan Chenkie
Ryan Chenkie
Founder @ CourseLift
Rate this content
Bookmark

Desarrollar una aplicación full-stack del mundo real a menudo implica un tedioso enhebrado de datos a través de múltiples capas del stack. Esto es particularmente indeseable durante las fases de prototipado donde el objetivo principal puede ser simplemente demostrar una idea o diseño. También es arriesgado cuando se va a producción, ya que las inconsistencias de datos entre las capas pueden provocar errores.

Nexus Schema es una biblioteca para construir APIs de GraphQL de manera code-first y type-safe, y puede ayudar enormemente con este dilema de velocidad y type-safety. En esta charla, veremos cómo construir APIs de GraphQL más rápido y con los beneficios de la type safety utilizando Nexus Schema.

graphql
Ryan Chenkie
Ryan Chenkie
25 min
02 Jul, 2021

Video Summary and Transcription

Esta charla discute los beneficios de un enfoque code-first para construir APIs de GraphQL utilizando Nexus Schema. Explora cómo el enfoque code-first simplifica el proceso de desarrollo al permitir que el esquema de GraphQL se defina en código, proporcionando flexibilidad y modularización fácil. Se demuestra la integración de una base de datos real con Prisma, mostrando la forma type-safe de acceder a la base de datos y generar lenguaje de definición de esquema y tipos como artefactos. La charla también destaca la madurez y el crecimiento de GraphQL como tecnología y la emoción que genera en la comunidad de desarrolladores.

Available in English

1. Introducción a las APIs de GraphQL con enfoque en el código

Short description:

Hola, soy Ryan. Hoy quiero hablar sobre un enfoque diferente para construir servidores de GraphQL. Discutiré las APIs de GraphQL con enfoque en el código utilizando Nexus Schema. Como defensor del desarrollo de GraphQL en Prisma, facilitamos el trabajo con bases de datos y proporcionamos acceso seguro al tipo de base de datos. Encuéntrame en Twitter @ryanchenke.

Hola, soy Ryan. Y hoy quiero hablarles sobre una forma de construir servidores de GraphQL que se ve un poco diferente a la forma típica que la gente suele tomar. El enfoque de construir una API de GraphQL basada en el esquema. Voy a hablar sobre las APIs de GraphQL con enfoque en el código, específicamente con Nexus Schema. Mi nombre es Ryan Chenke. Soy un defensor del desarrollo de GraphQL en Prisma. Y en Prisma, trabajamos con bases de datos. Facilitamos mucho comenzar con una base de datos y tenemos un ORM muy bueno para tu base de datos. Te brindamos acceso seguro al tipo de base de datos, lo cual es muy útil, especialmente si estás trabajando con TypeScript en Node.js. Puedes encontrarme en Twitter. Estoy en ryanchenke en Twitter.

2. Construcción de APIs de GraphQL con enfoque en el esquema primero

Short description:

Cuando construimos una API de GraphQL, a menudo comenzamos con un enfoque en el esquema utilizando el lenguaje de definición de esquema. Sin embargo, este enfoque puede presentar desafíos y complejidades que podrían abordarse mejor con un enfoque diferente.

Entonces hablemos de la construcción de APIs de GraphQL. Cuando nos disponemos a construir una API de GraphQL, y típicamente cuando estamos aprendiendo cómo construir una API de GraphQL, tomamos el enfoque de lo que llamamos esquema primero, y utilizamos lo que se llama el enfoque del lenguaje de definición de esquema para construir un servidor de GraphQL.

Y muchos de nosotros hemos visto esto si hemos pasado por las fases iniciales de comenzar, o incluso si hemos construido APIs completas de GraphQL, donde comenzamos con un lenguaje de definición de esquema, y definimos nuestros tipos y nuestros tipos de entrada y todo eso, y luego tenemos un conjunto de resolutores que se mapean a él. Pero esta no es la única forma de hacerlo. Aunque es fácil comenzar, presenta algunos desafíos con los que tendremos que lidiar en el camino.

La mayoría de los ejemplos muestran cómo hacer este enfoque de lenguaje de definición de esquema primero, especialmente si sigues los tutoriales de Apollo, por ejemplo. Vas a ver esta forma de construir un servidor de GraphQL primero con SDL, y es fácil comenzar, pero en última instancia puede llevar a algunas complejidades que se manejan mejor con un enfoque diferente. Esto es cómo se ve. Tendrías tu lenguaje de definición de esquema. Aquí tenemos un tipo de publicación y tres campos. Tenemos el ID, el título y el cuerpo. Puede que esto te resulte familiar. Luego tenemos nuestro tipo de consulta raíz, donde estamos devolviendo una lista de publicaciones.

3. Definición de esquema y enfoque en el código primero

Short description:

Al construir un servidor de GraphQL, se necesitan tanto un lenguaje de definición de esquema como resolutores. Sin embargo, trabajar con ellos por separado puede generar problemas, como desafíos de modularización y cambios frecuentes de contexto. Se requiere herramientas adicionales para el enfoque del lenguaje de definición de esquema primero. Alternativamente, el enfoque del código primero permite definir el esquema de GraphQL en código, lo que proporciona más flexibilidad.

Ahora, con un lenguaje de definición de esquema, esto no es todo lo que necesitas al escribir tu servidor. También necesitas un conjunto de resolutores. Para este ejemplo, necesitamos mapear un resolutor para nuestro tipo de consulta raíz, que puede devolver esas publicaciones. Son dos piezas de código diferentes. Está el lenguaje de definición de esquema y luego hay algún JavaScript u otro lenguaje en el que estemos trabajando que debemos tener en cuenta para que este servidor de GraphQL haga lo que debe hacer. Y esto, como mencioné antes, conlleva algunos problemas. Entonces, ¿cuáles son estos problemas? Bueno, cuando trabajamos con esquemas y resolutores por separado, están en diferentes lugares. Están en dos ubicaciones diferentes en el sistema de archivos. Nos encontramos con problemas de modularización. Entonces, si queremos tener una API de GraphQL grande, a menudo queremos dividir nuestro esquema en submódulos más pequeños. Y esto es posible, pero presenta algunos desafíos cuando se trata de unir todo al final, de unirlos todos en un servidor raíz. Entonces, tienes tus resolutores en un lugar, tienes tu esquema en otro lugar, y tienes que cambiar constantemente entre los dos. Tienes que hacer muchos cambios de contexto cuando estás escribiendo tu código. Y ese cambio de contexto, creo, tiene un costo. Estás trabajando en un tipo de lenguaje en un momento y luego en otro en otro momento. Y, ya sabes, esto puede parecer trivial si tienes mucha experiencia, pero incluso para aquellos de nosotros que tenemos mucha experiencia, tiene un costo cambiar constantemente entre estos dos modos de pensamiento. También necesitarás algunas herramientas cuando adoptes un enfoque del lenguaje de definición de esquema primero. Necesitas herramientas para resaltar adecuadamente tu lenguaje de definición de esquema en el código. Necesitas algunas extensiones en tu editor de código. Necesitas algunas cosas para modularizar tu esquema y los resolutores que lo acompañan. Entonces, hay una necesidad de herramientas adicionales si vas a trabajar de esta manera. Podemos adoptar un enfoque diferente. Podemos adoptar el enfoque del código primero para escribir APIs de GraphQL. Y lo que eso implica es algo así, esto es Nexus en este ejemplo, y estamos definiendo un esquema de GraphQL aquí, pero lo estamos haciendo todo en código. En este caso, estamos utilizando TypeScript. Tenemos esta cosa llamada object type de Nexus schema, que nos permite definir un tipo, en este caso, es ese tipo de publicación. Y luego tenemos este método de definición donde podemos decir que queremos un ID llamado ID. Eso es lo que estamos haciendo allí cuando hacemos t.dot ID. Y luego queremos algunas cadenas t.dot string con título y cuerpo. Esto nos da nuestro

4. Beneficios del enfoque del código primero

Short description:

El enfoque del código primero para las APIs de GraphQL tiene varios beneficios. Todo está en un solo lugar, lo que facilita el trabajo sin tener que cambiar entre archivos. La modularización se vuelve sencilla al importar y exportar piezas de TypeScript o JavaScript. Obtenemos beneficios adicionales como la generación de código y la capacidad de comunicar la estructura de la API a las aplicaciones front-end. La colaboración también es más fácil con el enfoque del código primero.

El lenguaje de definición de esquema de GraphQL, pero lo hemos hecho en código. Entonces, ¿cuál es el beneficio de esto? Bueno, si pasamos a nuestro tipo de consulta raíz, se vuelve realmente interesante. Lo que estamos haciendo aquí es decir que en el tipo de consulta raíz, queremos un campo llamado publicaciones, y le estamos diciendo cómo resolverlo con los datos para ese campo de publicación aquí mismo. Entonces, hemos hecho todo el trabajo para crear un esquema de GraphQL y el resolutor asociado para el tipo de publicación en este caso, todo en el mismo lugar. Es solo un archivo en el que estamos trabajando, no es necesario cambiar de contexto entre diferentes tipos de código, y hemos logrado todo lo que necesitamos aquí. Entonces, el enfoque del código primero para las APIs de GraphQL tiene varios beneficios. Nuevamente, todo está en un solo lugar, no es necesario cambiar constantemente entre diferentes archivos. La parte de modularización se vuelve bastante fácil, porque en lugar de utilizar herramientas adicionales para modularizar un esquema, simplemente importamos y exportamos piezas de TypeScript o JavaScript, y luego las podemos llevar a un archivo raíz y servirlas. Por lo tanto, se vuelve muy fácil servir tu API de GraphQL de esa manera. No es necesario utilizar herramientas adicionales para hacer el trabajo. Todo es simplemente JavaScript o TypeScript. Y obtenemos algunos beneficios adicionales con esto. Si estamos utilizando Nexus, por ejemplo, tenemos la generación de código en funcionamiento. Obtenemos artefactos generados como el archivo de lenguaje de definición de esquema y un conjunto de tipos asociados con nuestra API. Y eso es beneficioso para utilizar diferentes extensiones en nuestros editores, por ejemplo. Por lo tanto, podemos tomar nuestro SDL y decirle a nuestras aplicaciones front-end qué podemos consultar desde nuestro backend solo en función de ese SDL. Y se vuelve muy fácil obtener todos los beneficios que tendríamos de un archivo de lenguaje de definición de esquema, junto con un enfoque del código primero. Y en última instancia, podemos movernos fácil y rápidamente, colaborar

5. Nexus Schema-powered GraphQL API

Short description:

Echemos un vistazo a una API de GraphQL básica impulsada por Nexus Schema utilizando Apollo Server. Con Nexus Schema, podemos definir nuestro tipo de consulta y su resolución en un solo lugar, eliminando la necesidad de separación.

Podemos desarrollar fácil y rápidamente si también utilizamos un enfoque del código primero. Entonces veamos cómo podría funcionar esto. Hagamos una demostración. Aquí tenemos una API de GraphQL básica impulsada por Nexus Schema y está utilizando Apollo Server. En última instancia, necesitamos un servidor para servir esto, pero estamos construyendo esta API con Nexus Schema. Y si vamos al navegador, tenemos este simple ejemplo de hola mundo en funcionamiento en este momento. Y eso nos da una API basada en este código aquí. Estamos definiendo nuestro tipo de consulta. Le estamos diciendo cómo resolver todo en un solo lugar. No es necesario separar esas cosas.

6. Creando API para Planetas con Nexus Schema

Short description:

Creemos una API para planetas utilizando el tipo de objeto en Nexus schema. Definamos el tipo de planeta con campos de ID, nombre y tipo. Incluyamos el tipo de planeta en el array de tipos para que esté disponible. En el tipo de consulta raíz, agreguemos un campo de lista llamado planetas y especifiquemos el tipo de planeta para resolverlo. Establezcamos una función de resolución para devolver un array de objetos de planetas. En el playground de GraphQL, consultemos los planetas con los campos de ID, nombre y tipo.

Entonces, pensé en lo que haremos, porque estamos aquí en GraphQL Galaxy, veamos cómo podemos crear un poco de una API para planetas para hablar sobre los planetas en nuestro sistema solar. Para hacer eso, crearíamos una constante y tal vez la llamemos planetas, y eso va a ser igual a algo llamado tipo de objeto. Queremos definir un tipo de objeto. Esto sería como, si estuvieras en tu lenguaje de definición de esquema, y estuvieras definiendo un tipo para algo.

Lo que sale de Nexus schema, tenemos que darle un nombre, así que llamémoslo planetas. Y luego le damos alguna definición. Y la definición, nuevamente, es algo donde hacemos como T.id para darnos un ID. Entonces es un tipo de ID y el nombre para ello va a ser ID. Y luego tengamos un campo de cadena, y le daremos el nombre del planeta, y otro campo de cadena para darle al planeta un tipo. Muy bien. Así que tenemos nuestro tipo de planeta. Tenemos que ponerlo aquí en el array de tipos cuando hagamos nuestro esquema, tiene que ir allí para que esté disponible.

Y luego en nuestro tipo de consulta raíz ahora, podemos definir algo además de este campo de cadena que tenemos. Y podemos decir que nos dé un campo de lista llamado planetas. Digamos que queremos tener algo que nos dé una lista de planetas. Tenemos que decirle qué tipo resolver. Queremos resolver con el tipo de planeta. Y luego podemos establecer un resolvedor. Entonces el resolvedor, la función resuelta podría verse así. Podemos devolver un array. Tendremos algunos objetos allí. Digamos que el id será 1. Y el nombre puede ser Tierra. Y el tipo puede ser rocoso. Algo así. Entonces si ahora volvemos a nuestro playground de GraphQL, veamos si podemos obtener eso. Podemos hacer planetas. Hacer id, nombre y tipo. Ahí lo tenemos. Tenemos nuestro array de planetas devuelto.

7. Integrando una Base de Datos Real con Prisma

Short description:

Podemos integrar fácilmente una base de datos real en nuestra API utilizando Prisma. Al ejecutar 'npx prisma init', creamos un archivo Prisma que proporciona un esquema. Podemos elegir diferentes bases de datos, como SQLite, y definir nuestro modelo, incluyendo los campos de id, nombre y tipo. Al ejecutar 'npx prisma db push', insertamos el dev.db en Prisma, lo que nos permite explorar la base de datos utilizando 'npx prisma studio'.

Y no necesitamos, una vez más, definir un esquema y luego definir resolutores. Todo está sucediendo en un solo lugar aquí. Así que es una forma realmente poderosa de integrar todo para crear nuestra API.

Veamos cómo podemos obtener una base de datos real aquí. Y podemos hacerlo muy fácilmente con Prisma. Prisma se integra muy bien con GraphQL y en particular con Nexus. Ya tengo Prisma instalado. Y para ponerlo en marcha, puedo hacer npx prisma init, así. Y lo que hará es crear este archivo Prisma, que me da un esquema, este archivo de esquema.prisma. Y hay varios tipos de bases de datos compatibles. Voy a usar SQLite, una base de datos de sistema de archivos en este caso, solo para fines de demostración. Y eso apuntará a un archivo llamado dev.db. Luego puedo crear un modelo. Y el modelo será planetas. Esto se mapea a una tabla que crearemos en la base de datos. Y tendremos un id, lo estableceremos como tipo cadena. Y diremos que este será el id, esta será la clave primaria de esta tabla. Y el valor predeterminado, le daremos un valor predeterminado, puede ser un id universal resistente a colisiones. Queremos el nombre como una cadena. Y también queremos el tipo como una cadena. Eso es todo lo que necesitamos para nuestro modelo de base de datos.

Luego podemos hacer esto. Podemos hacer npx prisma db push. Y esto es en realidad una función de vista previa en este momento. Así que simplemente pasaremos esa bandera. Y si lo hacemos, obtenemos un dev.db insertado en nuestro Prisma. Esta es nuestra base de datos en sí para SQLite. Y echemos un vistazo a esta base de datos. npx prisma studio nos brinda una interfaz gráfica para ver qué hay dentro de nuestra base de datos. Y

8. Añadiendo Registros y Accediendo a la Base de Datos

Short description:

Podemos agregar registros para la Tierra, Marte y Júpiter a nuestra base de datos. Importando Prisma y utilizando los Prisma Clients, podemos acceder a los planetas en nuestra base de datos y devolverlos en nuestra API de GraphQL. Este enfoque de código primero proporciona los beneficios de un acceso seguro al tipo de base de datos y la capacidad de generar el lenguaje de definición de esquema y los tipos como artefactos.

podemos ver que tenemos nuestra tabla de planetas. Podemos agregar algunos registros. Así que digamos que el tipo de la Tierra es Roca. Podemos agregar un par más. Digamos que Marte. Eso también es Roca. Y agregaremos uno más, Júpiter, es un gigante gaseoso. Bien, guardaremos esos tres cambios. Así que eso está en nuestra database. Estamos listos para continuar. Y ahora en nuestro server.ts, vamos a importar Prisma para hacer realmente este trabajo. Podemos importar los Prisma Clients de Prisma Clients. Y luego podemos decir const Prisma equals a new Prisma Clients. Podemos ver lo que está disponible en Prisma si simplemente hacemos un punto y de inmediato vamos a esta propiedad de planetas. Y esto se mapea a nuestra database. Básicamente, obtenemos toda la información de tipo generada que necesitaríamos para hacer nuestras consultas. Así que si queremos resolver con los planetas de nuestra database, podemos hacer esto. Devolveremos Prisma planets find many. Y si hacemos eso, y volvemos a nuestro playground gráfico, vamos a hacer clic en eso. Y obtenemos todos los planetas que salen de nuestra database.

Así que inmediatamente aquí, tenemos los beneficios de la API de GraphQL escrita de una manera de código primero y una forma segura de acceder a nuestra database. Una última cosa que mostraremos es cómo obtener ese SDL producido como un artefacto de este enfoque de código primero. Y para hacer eso, podemos hacer algo aquí en nuestro make schema, donde definimos algunas salidas. Y hay dos en las que podríamos estar interesados, una sería el esquema. Y para esto, hagamos esto, diremos el nombre del directorio slash generated slash schema.graphql, schema.graphql. Así que eso es una cosa que podríamos querer. Y también podríamos querer TypeGen, que generará los tipos para nosotros. Y para esto, podemos decir tal vez types.ts. Y lo que deberíamos obtener si guardo esto, inmediatamente veremos que aparece esta carpeta generada aquí. Si echamos un vistazo, tenemos el lenguaje de definición de esquema que se mapea al esquema que hemos definido con Nexus. Así que básicamente, tenemos todos los beneficios de

9. Simplificando el desarrollo de API de GraphQL con Prisma

Short description:

No tenemos que movernos por todo nuestro sistema de archivos. Podemos definir todo en el mismo lugar, tanto nuestro esquema como nuestros resolvers, pero también obtenemos el esquema para la parte real de nuestro API de GraphQL que se produce para nosotros, y podemos usar esto en otros lugares. Y luego obtenemos un conjunto de tipos que vienen aquí y que podemos usar en toda nuestra aplicación. Y donde se vuelve realmente interesante, especialmente con Prisma en la mezcla, es que Prisma nos proporciona la información de tipo para nuestro API, esencialmente, nuestra base de datos. Y así podemos usar este tipo de planeta, por ejemplo, en varios lugares de nuestra aplicación. El beneficio aquí es que un enfoque de código primero nos va a dar una forma fácil de permanecer en el mismo lugar, no tener que cambiar de contexto, no tener que utilizar herramientas adicionales y, en última instancia, nos brinda una experiencia de desarrollo realmente agradable al construir un API de GraphQL. Si quieres obtener las diapositivas de esta charla, puedes ir a este enlace. Es un enlace de bitly, /GraphQLGalaxy te llevará a las diapositivas. Puedes visitarnos. Puedes encontrarme en Twitter, si quieres. Ryan Shanky es mi nombre de usuario en Twitter. Puedes visitar Prisma en Twitter, está en Prisma. O visita Prisma.io para obtener más información si estás interesado en Prisma o Nexus, porque Prisma se encarga del esquema de Nexus como colaborador, autor, y puedes obtener más información sobre todo esto si nos visitas en Twitter o vas a Prisma.io. Gracias.

un enfoque de código primero. No tenemos que movernos por todo nuestro sistema de archivos. Podemos definir todo en el mismo lugar, tanto nuestro esquema como nuestros resolvers, pero también obtenemos el esquema para la parte real de nuestro API de GraphQL que se produce para nosotros, y podemos usar esto en otros lugares. Y luego obtenemos un conjunto de tipos que vienen aquí y que podemos usar en toda nuestra aplicación. Y donde se vuelve realmente interesante, especialmente con Prisma en la mezcla, es que Prisma nos proporciona la información de tipo para nuestro API, esencialmente, nuestra base de datos. Y así podemos usar este tipo de planeta, por ejemplo, en varios lugares de nuestra aplicación. Entonces, nuevamente, el beneficio aquí es que un enfoque de código primero nos va a dar una forma fácil de permanecer en el mismo lugar, no tener que cambiar de contexto, no tener que utilizar herramientas adicionales y, en última instancia, nos brinda una experiencia de desarrollo realmente agradable al construir un API de GraphQL. Eso es todo para la demostración. Y eso es todo para la charla. Si quieres obtener las diapositivas de esta charla, puedes ir a este enlace. Es un enlace de bitly, /GraphQLGalaxy te llevará a las diapositivas. Puedes visitarnos. Puedes encontrarme en Twitter, si quieres. Ryan Shanky es mi nombre de usuario en Twitter. Puedes visitar Prisma en Twitter, está en Prisma. O visita Prisma.io para obtener más información si estás interesado en Prisma o Nexus, porque Prisma se encarga del esquema de Nexus como colaborador, autor, y puedes obtener más información sobre todo esto si nos visitas en Twitter o vas a Prisma.io.

10. Discusión sobre Nexus y Prisma

Short description:

¡Hola! ¿Cómo estás? Yo estoy bien. ¿Y tú? Estoy bien. Esa fue una charla maravillosa. Muchas gracias. Aprecio mucho. Increíble. Parece que la mayoría de las personas lo entendieron bien. Si te gustó la charla de Ryan, por favor envía emojis de aplausos virtuales para mostrar tu amor y apoyo a Ryan. En Discord, por cierto. Para alguien que es nuevo en Nexus o en las herramientas de Prisma, ¿qué es algo que te parece súper genial? Prisma proporciona un cliente de base de datos seguro en cuanto a tipos, soporte de migración y un cliente de estudio para visualización de datos. Permite escribir consultas de base de datos sin escribir SQL y garantiza la corrección de las consultas mediante la seguridad de tipos.

¡Gracias! ¡Hola! ¿Cómo estás? Yo estoy bien. ¿Y tú? Estoy bien. Esa fue una charla maravillosa. Muchas gracias. Aprecio mucho. Increíble. Entonces, ¿qué opinas del resultado? ¿Te sorprendieron las respuestas? Creo que es una buena proporción de los encuestados que lo respondieron correctamente. He hecho esta pregunta en otros eventos, esta misma pregunta, y es más o menos igual. Es como esa regla del 80-20, creo. Así que, ya sabes, el 80% de las personas lo respondieron correctamente. Y creo que cada uno de los beneficios individuales de Nexus que se vieron en las opciones, eso es solo una pequeña proporción, creo, de lo que realmente está disponible en cuanto a beneficios con Nexus. Esos son algunos de los más importantes, creo, que a la mayoría de las personas les gusta de Nexus, y hay muchos más. Pero sí, me alegró ver que la mayoría de las personas se dieron cuenta de que era todas las anteriores. Eso es genial. Parece que la mayoría de las personas lo entendieron bien. Además, solo un recordatorio, si te gustó la charla de Ryan, por favor envía emojis de aplausos virtuales para mostrar tu amor y apoyo a Ryan. En Discord, por cierto. Ahora vamos a ver algunas preguntas que un pajarito suele dejar en Discord. Pero tengo una pregunta antes de eso. Personalmente no he usado Nexus. Para alguien que es nuevo en Nexus o en las herramientas de Prisma, ¿qué es algo que te parece súper genial? Sé que recientemente comenzaste a trabajar en Prisma y te uniste al equipo de DevRel recientemente, y es posible que lo hayas estado viendo desde la perspectiva de alguien que es nuevo en estas herramientas. ¿Tienes alguna idea al respecto? ¿Qué es algo en lo que un principiante se fijaría? Sí, entonces, quiero decir, Prisma, lo que obtienes con Prisma es un cliente de base de datos seguro en cuanto a tipos, un cliente de acceso a la base de datos seguro en cuanto a tipos y muchas otras cosas también. Hay muchas herramientas, puedes obtener un cliente de estudio donde puedes visualizar tus datos y hay soporte de migración y todo ese tipo de cosas. Lo que realmente me gusta de Prisma es que realmente quiero trabajar con bases de datos relacionales, pero las formas típicas de hacerlo, escribir SQL a mano, hay otras opciones para ORMs y cosas así. Pero si estás buscando otros ORMs o escribiendo SQL a mano, las experiencias que he tenido, de todos modos, no han sido buenas con esas soluciones. Así que Prisma fue lo primero que usé donde pensé, esto es realmente genial. Puedo escribir una consulta de base de datos sin tener que escribir SQL y puedo asegurarme de que mi consulta sea correcta antes de ejecutar mi código porque todo está seguro en cuanto a tipos. Entonces, los clientes de Prisma realmente no te permitirán hacer algo que no debas hacer.

11. Beneficios de Nexus y enfoque de código primero

Short description:

Si has construido tu base de datos y configurado tus modelos de la manera que deseas, puedes confiar en que será una experiencia realmente segura mientras escribes tu código. Y me da más confianza cuando estoy poniendo mis bases de datos en el mundo real. En cuanto a Nexus en sí, es una experiencia agradable porque es bueno no tener que ir y venir entre escribir SDL y tus resolvers. Es bueno tener todo en un solo lugar. Es una buena combinación, creo.

con tu base de datos. Si has construido tu base de datos y configurado tus modelos de la manera que deseas, puedes confiar en que será una experiencia realmente segura mientras escribes tu código. Y me da más confianza cuando estoy poniendo mis bases de datos en el mundo real y creo que eso es lo que a mucha gente le gusta. En cuanto a Nexus en sí, no había usado mucho el enfoque de código primero antes de probar Nexus cuando me uní a Prisma. Y es una experiencia agradable porque, como mencioné en las diapositivas y en la pregunta, es bueno no tener que ir y venir entre escribir SDL y tus resolvers. Es bueno tener todo en un solo lugar. Es bueno tener los artefactos generados que obtienes de Nexus, como el lenguaje de definición de esquema que puedes utilizar en otras herramientas y cosas así. En general, ha sido simplemente una experiencia muy agradable trabajar con Nexus para APIs de GraphQL con enfoque de código primero.

12. Discusión sobre Nexus y Madurez de GraphQL

Short description:

Creo que hay margen de mejora en el proceso de configuración de las instancias de Nexus. Sería genial tener una gestión más automática y una configuración más sencilla. En cuanto a lo que me emociona de GraphQL, estoy entusiasmado con su etapa de madurez y las oportunidades que ofrece. GraphQL se está volviendo más establecido, estable y probado en batalla. Hay menos aprensión por parte de las organizaciones y se está compartiendo más conocimiento dentro de la comunidad.

más Prisma. Creo que es una buena combinación. Esa es una gran respuesta. Además, estoy pensando en voz alta procesando toda la información que diste en tu charla y también en tu respuesta. ¿Qué es algo que crees que haría que Nexus sea mucho mejor o un desafío que enfrentas al usarlo, hay algo así? Sí, quiero decir, hay un poco de cosas de configuración que debes hacer si quieres trabajar con complementos, por ejemplo, y en ciertos escenarios, hacer que las tipificaciones funcionen para ti. Así que hay un poco que se puede hacer, creo, para hacer que la tarea de configuración sea un poco más fácil, tener las cosas más automáticamente gestionadas para ti porque hay algunos puntos problemáticos en los que puedes encontrarte cuando estás configurando las cosas. Una vez que superas eso, es un camino tranquilo. Pero sí, creo que, ya sabes, es algo que definitivamente se debe considerar en el futuro para mejorar la experiencia del desarrollador es tener instancias de Nexus más fácilmente configurables, ese tipo de cosas. Absolutamente. Creo que sí, creo que eso es correcto. Esa es una gran respuesta. Veo que actualmente no tenemos ninguna pregunta para ti en Discord. Así que antes de terminar esto, mi última pregunta para Ryan sería, ¿qué es algo que te emociona de GraphQL? Dado que estamos en esta encantadora conferencia llamada GraphQL Galaxy, hay un universo de entusiastas de GraphQL que están explorando las posibilidades que GraphQL ofrece. ¿Qué es algo que te emociona? ¿Algo a lo que estás deseando? Sí, bueno, algo en lo que he estado pensando es cómo GraphQL está llegando a una etapa. Lo que me parece es una especie de etapa de madurez donde había mucho entusiasmo por GraphQL en los primeros días, y todavía hay mucho entusiasmo, pero había mucho entusiasmo. La gente estaba descubriendo cosas. No todo lo que quisieras construir en una aplicación realmente estaba en la especificación de GraphQL. Solo había una pequeña parte de cosas que estarían en la especificación a las que irías y aplicarías a bibliotecas y cosas así. Así que la gente estaba descubriendo cosas por su cuenta, en sus propias bibliotecas y cosas así. Y creo que ahora estamos llegando a este punto en el que se están acordando cada vez más cosas, se están acordando convenciones, las cosas están llegando a la especificación ahora. Eso tiene mucho trabajo en ello. Así que estamos alcanzando esta etapa de madurez, creo, con GraphQL, lo cual es emocionante por dos razones. Creo que porque la etapa en la que está GraphQL, todavía tiene mucho entusiasmo detrás, pero también tal vez podrías considerarlo mucho más estable. Hay menos aprensión por parte de las organizaciones para adoptar GraphQL porque ahora está más establecido, se está haciendo más trabajo en ello. Así que creo que eso es emocionante porque hay más oportunidades para los desarrolladores de GraphQL trabajar con GraphQL en nuevos trabajos si así lo desean. Personalmente, me encanta trabajar con ello, así que si tengo la oportunidad de trabajar con personas en proyectos de GraphQL, es genial. Y, sí, la madurez de ello, está llegando a ser como una especie de, cada vez más probado en batalla, creo que es genial. Así que eso me emociona bastante. Y, ya sabes, creo que también hay mucho más intercambio de conocimientos que está sucediendo dentro de la comunidad ahora. Y pienso en cosas como el libro de Marc-André Giroud que salió sobre cómo construir servidores GraphQL y cómo construir una aplicación GraphQL, ya sabes, que escala. Eso es un gran ejemplo de alguien que ha pasado por algo realmente intenso, como la aplicación GraphQL más intensa que podrías construir en lugares como Shopify y GitHub, y compartir ese conocimiento. Así que estoy realmente emocionado por todo el intercambio de conocimientos que está sucediendo, lo cual involucra a más personas en

13. Emoción por el Crecimiento de GraphQL

Short description:

GraphQL está madurando y creciendo como tecnología, junto con la comunidad y las herramientas que la utilizan. Es emocionante ver a los desarrolladores trabajando en GraphQL y el progreso que se está haciendo. Gracias por estar aquí y por la excelente sesión de preguntas y respuestas, Ryan.

el mundo de GraphQL cada vez más. Sí, definitivamente puedo relacionarme con tu respuesta. Porque algo como una tecnología tan joven como GraphQL, ahora está madurando y es genial ver cómo, a medida que la comunidad crece,GraphQL como tecnología en sí misma también crece, todas las herramientas que utilizan GraphQL, ya sabes, todas estas increíbles soluciones y productos que utilizan GraphQL, también están creciendo y es una experiencia realmente gratificante ver que eso sucede. Cada vez que veo una oferta de trabajo de GraphQL, me emociona saber que hay desarrolladores reales trabajando en esto y en estas cosas, creo. Sí, definitivamente. De acuerdo. Es genial, estoy emocionado de estar aquí. Muchas gracias. Fue un placer tenerte con nosotros y esa fue una increíble sesión de preguntas y respuestas contigo. Gracias, Ryan. Gracias, aprecio eso. Gracias. Bueno, adiós.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

From GraphQL Zero to GraphQL Hero with RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
Tom Preston-Werner
Tom Preston-Werner
GitHub cofounder, RedwoodJS author
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
graphqlredwoodjsframeworksbuilders and founders
Local State and Server Cache: Finding a Balance
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
Natalia Tepluhina
Natalia Tepluhina
GitLab
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
graphqlserver cachevue
Batteries Included Reimagined - The Revival of GraphQL Yoga
GraphQL Galaxy 2021GraphQL Galaxy 2021
33 min
Batteries Included Reimagined - The Revival of GraphQL Yoga
Uri Goldshtein
Uri Goldshtein
Founder of The Guild, the largest open source group in GraphQL ecosystem.
The Guild has recently released Envelop - a new, modern GraphQL Server Framework and plugin system. In this talk I’ll share a brief overview of Envelop and why you should probably upgrade your existing GraphQL server to it.
graphqlreact server components
Rock Solid React and GraphQL Apps for People in a Hurry
GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Rock Solid React and GraphQL Apps for People in a Hurry
Ryan Chenkie
Ryan Chenkie
Founder @ CourseLift
In this talk, we'll look at some of the modern options for building a full-stack React and GraphQL app with strong conventions and how this can be of enormous benefit to you and your team. We'll focus specifically on RedwoodJS, a full stack React framework that is often called 'Ruby on Rails for React'.
graphqlreact
Adopting GraphQL in an Enterprise
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
Adopting GraphQL in an Enterprise
Shruti Kapoor
Shruti Kapoor
Lead Front End Engineer @ Slack
graphqlenterprise
Step aside resolvers: a new approach to GraphQL execution
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Step aside resolvers: a new approach to GraphQL execution
Benjie
Benjie
GraphQL Technical Steering Committee
Though GraphQL is declarative, resolvers operate field-by-field, layer-by-layer, often resulting in unnecessary work for your business logic even when using techniques such as DataLoader. In this talk, Benjie will introduce his vision for a new general-purpose GraphQL execution strategy whose holistic approach could lead to significant efficiency and scalability gains for all GraphQL APIs.
graphqlapi development

Workshops on related topic

Build with SvelteKit and GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Scott Spence
Scott Spence
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
sveltegraphql
End-To-End Type Safety with React, GraphQL & Prisma
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
Sabin Adams
Sabin Adams
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
graphqlprismareact
GraphQL for React Developers
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
Roy Derks
Roy Derks
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
graphqlreact
Build a Headless WordPress App with Next.js and WPGraphQL
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
Kellen Mace
Kellen Mace
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
graphqlwordpressnext.js
Relational Database Modeling for GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
WorkshopFree
Adron Hall
Adron Hall
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
graphqldatabase
Building GraphQL APIs on top of Ethereum with The Graph
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
WorkshopFree
Nader Dabit
Nader Dabit
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.
graphqlapi developmentethereum