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.
This talk has been presented at GraphQL Galaxy 2020, check out the latest edition of this Tech Conference.
FAQ
El enfoque del código primero para crear APIs de GraphQL implica definir el esquema y los resolutores directamente en el código, utilizando un lenguaje de programación como TypeScript, en lugar de definir primero el esquema en SDL (Lenguaje de Definición de Esquema). Este método permite una mayor cohesión y reduce la necesidad de cambiar entre diferentes tipos de archivos o contextos de codificación.
Nexus Schema facilita la definición de esquemas y resolutores de GraphQL directamente en el código, lo que ayuda a mantener todo en un solo lugar y simplifica la modularización. Además, proporciona generación de código automática que puede ser utilizada para mejorar la integración y coherencia en el desarrollo de aplicaciones.
Prisma se utiliza como un ORM que facilita la interacción con bases de datos en aplicaciones GraphQL, especialmente cuando se utiliza junto con Nexus Schema. Prisma proporciona un acceso seguro y tipificado a las bases de datos, lo que es especialmente útil en aplicaciones que utilizan TypeScript, mejorando la seguridad y eficiencia del acceso a datos.
El enfoque basado en SDL para GraphQL, aunque es fácil de comenzar, puede llevar a complejidades y desafíos en la gestión del esquema y los resolutores, que suelen estar en diferentes lugares. Esto puede causar problemas de modularización y requiere un constante cambio de contexto que puede ser ineficiente y propenso a errores.
Con el enfoque basado en SDL, generalmente se requieren herramientas adicionales para resaltar adecuadamente el SDL en el código, extensiones en editores de código, y herramientas para modularizar el esquema y los resolutores asociados, lo cual puede complicar el proceso de desarrollo.
Prisma es un ORM que permite una fácil configuración y manejo de bases de datos en aplicaciones modernas. Ofrece un acceso seguro y tipificado a las bases de datos, lo que facilita considerablemente las operaciones de bases de datos, especialmente en aplicaciones que utilizan TypeScript, mejorando la seguridad y la eficiencia en el manejo de datos.
El enfoque de código primero ofrece ventajas como la centralización del código, reducción de la necesidad de cambiar de contexto y simplificación de la modularización. También elimina la necesidad de herramientas adicionales para la gestión de esquemas y resolutores, lo que puede resultar en un desarrollo más rápido y eficiente.
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.
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.
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
This Talk discusses handling local state in software development, particularly when dealing with asynchronous behavior and API requests. It explores the challenges of managing global state and the need for actions when handling server data. The Talk also highlights the issue of fetching data not in Vuex and the challenges of keeping data up-to-date in Vuex. It mentions alternative tools like Apollo Client and React Query for handling local state. The Talk concludes with a discussion on GitLab going public and the celebration that followed.
Envelope is a powerful GraphQL plugin system that simplifies server development and allows for powerful plugin integration. It provides conformity for large corporations with multiple GraphQL servers and can be used with various frameworks. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild offers GraphQL Hive, a service similar to Apollo Studio, and encourages collaboration with other frameworks and languages.
The Talk discusses the challenges and advancements in using GraphQL and React together. It introduces RedwoodJS, a framework that simplifies frontend-backend integration and provides features like code generation, scaffolding, and authentication. The Talk demonstrates how to set up a Redwood project, generate layouts and models, and perform CRUD operations. Redwood automates many GraphQL parts and provides an easy way for developers to get started with GraphQL. It also highlights the benefits of Redwood and suggests checking out RedwoodJS.com for more information.
Today's Talk is about adopting GraphQL in an enterprise. It discusses the challenges of using REST APIs and the benefits of GraphQL. The Talk explores different approaches to adopting GraphQL, including coexistence with REST APIs. It emphasizes the power of GraphQL and provides tips for successful adoption. Overall, the Talk highlights the advantages of GraphQL in terms of efficiency, collaboration, and control over APIs.
GraphQL has made a huge impact in the way we build client applications, websites, and mobile apps. Despite the dominance of resolvers, the GraphQL specification does not mandate their use. Introducing Graphast, a new project that compiles GraphQL operations into execution and output plans, providing advanced optimizations. In GraphFast, instead of resolvers, we have plan resolvers that deal with future data. Graphfast plan resolvers are short and efficient, supporting all features of modern GraphQL.
¿Alguna vez has pensado en construir algo que no requiera mucho código de plantilla con un tamaño de paquete pequeño? En esta masterclass, Scott Spence irá desde el hola mundo hasta cubrir el enrutamiento y el uso de endpoints en SvelteKit. Configurarás una API de GraphQL en el backend y luego usarás consultas de GraphQL con SvelteKit para mostrar los datos de la API de GraphQL. Construirás un proyecto rápido y seguro que utiliza las características de SvelteKit, y luego lo desplegarás como un sitio completamente estático. Este curso es para los curiosos de Svelte que no han tenido una experiencia extensa con SvelteKit y quieren una comprensión más profunda de cómo usarlo en aplicaciones prácticas.
Tabla de contenidos: - Inicio e introducción a Svelte - Inicializar el proyecto frontend - Recorrido por el proyecto esqueleto de SvelteKit - Configurar el proyecto backend - Consultar datos con GraphQL - Recuperación de datos en el frontend con GraphQL - Estilización - Directivas de Svelte - Enrutamiento en SvelteKit - Endpoints en SvelteKit - Despliegue en Netlify - Navegación - Mutaciones en GraphCMS - Envío de mutaciones GraphQL a través de SvelteKit - Preguntas y respuestas
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Featured Workshop
2 authors
Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.
En este masterclass, obtendrás una visión de primera mano de lo que es la seguridad de tipo de extremo a extremo y por qué es importante. Para lograr esto, construirás una API de GraphQL utilizando herramientas modernas y relevantes que serán consumidas por un cliente de React. Prerrequisitos: - Node.js instalado en tu máquina (12.2.X / 14.X)- Se recomienda (pero no es obligatorio) utilizar VS Code para las tareas prácticas- Un IDE instalado (se recomienda VSCode)- (Bueno tener) *Un conocimiento básico de Node.js, React y TypeScript
Hay muchas ventajas en utilizar GraphQL como fuente de datos para el desarrollo frontend, en comparación con las API REST. Nosotros, los desarrolladores, por ejemplo, necesitamos escribir mucho código imperativo para recuperar datos y mostrarlos en nuestras aplicaciones y manejar el estado. Con GraphQL, no solo puedes reducir la cantidad de código necesario para la obtención de datos y la gestión del estado, sino que también obtendrás una mayor flexibilidad, mejor rendimiento y, sobre todo, una mejor experiencia de desarrollo. En este masterclass aprenderás cómo GraphQL puede mejorar tu trabajo como desarrollador frontend y cómo manejar GraphQL en tu aplicación frontend de React.
En esta masterclass, aprenderás cómo construir una aplicación Next.js que utiliza Apollo Client para obtener datos de un backend de WordPress sin cabeza y usarlo para renderizar las páginas de tu aplicación. Aprenderás cuándo debes considerar una arquitectura de WordPress sin cabeza, cómo convertir un backend de WordPress en un servidor GraphQL, cómo componer consultas usando el IDE GraphiQL, cómo colocar fragmentos GraphQL con tus componentes, y más.
En esta masterclass profundizaremos en el modelado de datos. Comenzaremos con una discusión sobre varios tipos de bases de datos y cómo se mapean a GraphQL. Una vez que se haya establecido esa base, el enfoque se desplazará a tipos específicos de bases de datos y cómo construir modelos de datos que funcionen mejor para GraphQL en varios escenarios. Índice de contenidosParte 1 - Hora 1 a. Modelado de Datos de Bases de Datos Relacionales b. Comparando Bases de Datos Relacionales y NoSQL c. GraphQL con la Base de Datos en menteParte 2 - Hora 2 a. Diseño de Modelos de Datos Relacionales b. Relación, Construcción de Tablas Multijoin c. Complejidades de Consulta de Modelado de Datos Relacionales y GraphQL Prerrequisitos a. Herramienta de modelado de datos. El formador utilizará dbdiagram b. Postgres, aunque no es necesario instalar esto localmente, ya que estaré utilizando una imagen de Dicker de Postgres, de Docker Hub para todos los ejemplos c. Hasura
Comments