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

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.

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.

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

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.

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

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