Crear y Desplegar APIs GraphQL Instantáneas en el Edge

React-JS para el Masterclass. Muchas gracias. Es genial estar aquí. Creo que ya estoy listo, estaba conectando algunas pantallas para ayudarnos a empezar hoy.

Así que esta primera diapositiva habla sobre el mundo de hoy lleno de diferentes APIs que tenemos. Tenemos tantos SDK y APIs diferentes que, honestamente, la documentación de todos ellos varía mucho, la experiencia del desarrollador, todas esas cosas son muy, muy diferentes. Y estos son solo algunos de los logotipos que creo que usamos hoy en día, desde bases de datos, hasta CMS, sistemas de gestión de contenido, APIs de comercio, hay mucho. Y sí, pasamos mucho tiempo conectando todas estas cosas y aprendiendo los diferentes SDK y APIs y no creo que sea la mejor experiencia. Y lo otro también, estrechamente relacionado con esto, es que esas fuentes de datos a menudo están en una sola región. Y si, en un caso muy grande, el proveedor que estás utilizando te da la flexibilidad de expandir esto, de expandir cualquier servicio que tengas a diferentes regiones alrededor del mundo, a menudo tienes que pagar por esa flexibilidad. Y cuanto más servicios tienes y más regiones en las que quieres estar, más te va a costar, y eso no es un buen lugar para estar. Eso es lo que estamos tratando de resolver en GraphBase. Aquí somos una empresa de GraphQL, y queremos resolver este problema. Así que a un nivel muy alto, cuando estás usando algo como GraphBase, obtienes tiempos de respuesta realmente rápidos en lugar de tener que ir a diferentes regiones. Por defecto, proporcionamos la API de GraphQL para todas tus diferentes fuentes de datos en el borde alrededor del mundo en más de 300 ubicaciones. Por lo tanto, es muy probable que tu usuario reciba una respuesta en menos de 50 milisegundos cuando realice una solicitud.

Lo primero que quiero cubrir en el masterclass de hoy es la conexión a una API existente. Si hay alguna API que estés utilizando actualmente, siéntete libre de dejar un comentario en el chat sobre las APIs que estás utilizando y podemos intentar conectar algunas de ellas. Siéntete libre de seguirme mientras lo hago y utiliza tus propias APIs. Si quieres utilizar las APIs que yo utilizo, obviamente, las mostraré en pantalla y también las puedo compartir en el chat.

Lo primero que haremos en el masterclass es conectarnos a nuestras fuentes de datos y la conexión a las diferentes fuentes de datos se ve algo así. Esto aún no está en el código, pero esto es lo que haremos en unos minutos. Utilizaremos el conector de GraphQL. También utilizaremos el conector de OpenAPI y también echaremos un vistazo muy breve al conector de MongoDB. Si tenemos tiempo, también te mostraré el conector de Postgres que lanzaremos en unas semanas.

Una vez que hayamos realizado la conexión, podemos pasar a implementar eso utilizando la línea de comandos o podemos conectarlo a un repositorio de GitHub y podemos implementarlo. Creo que para el masterclass de hoy, nos centraremos principalmente en el entorno local. Quiero mostrar lo fácil que es construir APIs de GraphQL localmente sin tener que implementar. Pero una vez que desees implementarlo y hacerlo disponible para tus aplicaciones, todo lo que necesitas hacer es ejecutar mpx graph-based dev. Te pedirá que inicies sesión, obviamente, si no lo has hecho antes. Y luego sí, puedes implementarlo. Y lo que hacemos internamente es implementarlo en el borde y utilizamos todo lo que está escrito en. Ups. ¿Qué ha pasado ahí? Ahí vamos. Así que todo está escrito en Rust, todo el motor de Graphbase está escrito en Rust. Y luego empaquetamos eso utilizando WebAssembly y lo implementamos en todo el mundo, utilizamos Cloudflare, por lo que lo implementamos en la red de Cloudflare, lo cual es bastante genial. Muy bien. Y por último, exploraremos cómo realizar diferentes consultas a todas estas APIs. Algunas son APIs de GraphQL, algunas son de MongoDB, y algunas son APIs REST, aunque no lo creas. Hay una herramienta, pathfinder.dev, que puedes utilizar para seguir y realizar consultas. Utilizaremos la versión que está alojada con la CLI, pero si quieres utilizar cualquier API de GraphQL y realizar operaciones, tenemos esta herramienta genial. Y esta es una descripción general de todo lo que veremos hoy. Así que creo que estamos listos para sumergirnos en todo. Si hay alguna pregunta, por favor avísame. Pero primero y ante todo, creo que simplemente debemos comenzar. También estoy abriendo Discord, así que si alguien tiene alguna pregunta, por favor avísame. Y por favor mencióname en el chat también.

Muy bien, comencemos por crear un nuevo proyecto. Vamos a aumentar el tamaño de la fuente aquí para poder ver lo que está sucediendo. Y aquí podemos usar NPX Graphbase Init. Obviamente, si tienes NPM instalado, podrás ejecutar esto. Y luego todo lo que necesitas hacer es darle un nombre a tu proyecto. Ahora, si tienes un proyecto existente, digamos que es una aplicación Astro, digamos que es una aplicación View, una aplicación React, una aplicación Angular, cualquier tipo de aplicación, tal vez sea una aplicación móvil con algo como uno de los frameworks móviles, también puedes usar eso. También puedes usar Graphbase dentro de eso. Entonces, donde sea que esté tu proyecto, si ya tienes algo, cambia al directorio de ese proyecto ahora dentro de la terminal. Y luego procede a ejecutar NPX Graphbase Init. Debido a que hoy no estoy dentro de un proyecto existente, simplemente estoy creando un backend de GraphQL desde cero sin un frontend. Nos centraremos solo en el elemento del servidor aquí. Voy a darle a mi proyecto un nombre. Así que simplemente lo llamaré TS Workshop. Y luego lo que hará esto es preguntarme qué tipo de configuración me gustaría utilizar para construir y configurar mi backend de Graphbase. Me gusta TypeScript, así que elegiré eso y parece muy apropiado dado que esto es TS Congress. Y una vez hecho eso, obtendremos una carpeta con un archivo para nuestra configuración. Entonces, si cambiamos al directorio TS Workshop ahora y lo abriré en mi editor de código. Si echamos un vistazo y vemos lo que nos ha dado, podemos ver que tenemos una carpeta llamada Graphbase. Tenemos un package JSON, que tiene algunos datos aquí.

Y luego tenemos un archivo de configuración. Ahora este archivo de configuración, lo podemos eliminar para este masterclass porque vamos a hacer todo en etapas aquí. Así que simplemente eliminemos parte del código base. Y esto es lo que nos queda. Esto es todo lo que necesitas para seguir adelante en este punto.

Hay una cosa que necesitaremos hacer y eso es instalar la última versión del SDK de GraphBase. Acabamos de lanzar una nueva versión. Así que necesitarás ejecutar esa instalación para el SDK. Y lo que esto hace es simplemente actualizar esta versión aquí y eso significa que tenemos acceso a todos los últimos conectores. Así que si no ves un conector, si estás viendo esto más tarde bajo demanda, necesitarás instalar la última versión del SDK. Y este package.json sería un package.json dentro de tu aplicación front-end. Todo lo que GraphBase init haría es agregar esta dependencia a tus dependencias existentes. Pero nosotros simplemente lo llamamos TS workshop cuando inicializamos el proyecto.

Así que vamos a comenzar haciendo algo muy, muy básico. Si alguien ha creado una API de GraphQL, por favor avísame en el chat si has creado una antes. Si no lo has hecho, vamos a explorar cómo crear una consulta y un resolver de GraphQL. Y la forma en que podemos hacerlo es utilizando este ayudante g. Y esto utiliza el patrón builder aquí para construir sobre G, que es nuestro esquema, y luego podemos darle un nombre a la consulta. Y la consulta aquí, ¿por qué no hacemos el tradicional hola mundo? Pasaremos a cosas más emocionantes, por supuesto, a medida que avancemos aquí. Pero sí. Creemos una consulta, hola, y tal vez podamos darle un argumento. Y definiremos el campo del argumento y el nombre del argumento como name. Y luego aquí podemos decir que esto es una cadena. Y también podemos hacer esto opcional si queremos. De acuerdo. Y luego una vez que tengamos eso, necesitamos definir cómo funciona esta consulta. Y para hacer eso, podemos llamar al resolver aquí. Y podemos especificar el nombre del archivo del resolver que se ejecuta cuando ejecutamos una consulta de GraphQL. Hagámoslo muy simple aquí. Lo llamaremos Hello. Y por último, necesitamos especificar cuál es el tipo de retorno para esta consulta. Y aquí simplemente diré que esto es una respuesta de cadena. Podrías hacer que sea cualquier otra cosa. Podría ser un big int. Podría ser una fecha, una fecha y hora, un correo electrónico. Podría ser una enumeración. Pero con el fin de comenzar, solo queremos llamarlo una cadena. Así que ahora que tenemos esta consulta Hello, esto no hará nada por ahora. Todo lo que hará es generar un esquema de GraphQL. Y si ejecutamos el servidor de desarrollo local aquí utilizando npx graph-based dev, esto iniciará un servidor local al que luego podemos acceder en el puerto 4000. Así que si lo traemos aquí a la pantalla, si miramos dentro de aquí, tenemos una consulta, hola, con algunos argumentos de nombre. Si vamos a la pestaña aquí, podemos ver el esquema y podemos ver que tenemos un campo hola y tenemos un nombre de cadena que devuelve el tipo cadena que no es nulo. Así que esto es todo lo que hizo esa configuración. Aquí está el SDL si alguien está familiarizado con eso. Pero esta es una forma estándar y común. Podrías escribir esto a mano, pero con GraphBase podemos usar el SDK aquí, tenemos una type safety completa, no cometemos errores al definir el SDL, tenemos este patrón aquí. Entonces esto genera esto en GraphQL. Pero si intentamos ejecutar esta consulta, veamos qué sucede. Así que vamos a ejecutar una consulta de GraphQL, podemos omitir la consulta porque por defecto es una consulta. Podemos pasarle un nombre.

Digamos simplemente tscongress. Y ahora, si ejecutamos esto, las cosas van a explotar. La invocación falló. ¿Por qué sucedió eso? Bueno, dijimos que el archivo de resolver, hello, resuelve la consulta, hello. Pero no tenemos un archivo llamado hello. Entonces, lo que podemos hacer es dentro de GraphBase, podemos crear una nueva carpeta. Y esto es un atajo para crear esa carpeta, resolvers. Así que crearemos el archivo, hello. Y podemos llamarlo.js, o podemos llamarlo.ts. Siendo tscongress, creo que deberíamos usar TypeScript. En el futuro, admitiremos cosas como PHP y otros lenguajes, como Rust. Pero por ahora, solo admitimos JavaScript y TypeScript. Y nos encargamos de compilar todo eso. Así que no hay nada más que necesites hacer. No necesitas crear ningún script para compilar o hacer cualquier otra cosa.

Ahora, todo lo que este archivo espera, si estás siguiendo, es que exportes una función. Aquí simplemente llamaremos a una función por defecto. Y luego devolveremos una cadena. Y diremos hola, mundo. Ahora que eso está guardado, abrimos la terminal aquí. Podemos ver que el resolver intentó compilar inicialmente, pero no había ningún archivo. Ahora ha detectado un cambio. Y el servidor se está recargando. Así que si volvemos y ejecutamos esto una vez más, deberíamos ver que tenemos hola, mundo, en nuestra respuesta. Pero lo que no tenemos es ts, congress. Este es un argumento que especificamos en la configuración que generó el SDL, que se especifica aquí.

Ahora, si alguien ha trabajado con resolvers de GraphQL antes, sabrá que hay un cierto formato, una firma para los resolvers. Primero, tenemos el padre. Luego tenemos los argumentos. Luego tenemos el contexto. Y luego tenemos info. Si trabajamos en orden inverso, info contiene información sobre la consulta actual. Por lo tanto, puede contener un AST de cómo se ve la consulta, cualquier argumento que se haya pasado, cualquier directiva que se haya utilizado. Entonces, si hacemos cosas dentro del código para determinar la mejor manera de planificar consultas o proyectar consultas en bases de datos, lo tenemos. Ahora, para esto, en realidad no necesitamos eso. Y luego, para el contexto, con el contexto en GraphBase, podemos acceder a cosas sobre la solicitud actual. Por lo tanto, podrían ser cosas como encabezados de autorización u otras variables de contexto que provienen de la configuración del servidor. Y luego tenemos los argumentos, que se pasan a la consulta. Y esto es lo que necesitaremos para esta parte. Y por último, el padre, esto es lo que podemos usar para acceder al padre o la consulta raíz. Ahora, tenemos una consulta raíz, hello, aquí, por lo que no hay un padre o un padre de eso. Es en sí misma la consulta raíz. Pero si este fuera un resolver dentro de un tipo anidado, podemos acceder a ese padre data. Y lo veremos un poco más adelante. Así que ignoremos ese campo porque solo nos importan los argumentos aquí. Y luego, lo que vamos a hacer con eso es devolver aquí, simplemente devolver el nombre, así que llamaremos a args.name. Y si esto no existe, simplemente devolveremos world. Así que con suerte, todo eso debería funcionar. Si puedo escribir TypeScript correctamente, esto debería estar bien, creo. Creo que sí. En realidad, no. Necesitaremos el... ¿Dónde se fue? Creo que eso debería funcionar. Corrígeme si me equivoco. De todos modos, lo ejecutaremos. Y ahí lo tenemos. Obtenemos ese hola, TS Congress en nuestra respuesta, porque obtuvo el valor aquí. Ahora, como eso era opcional, por supuesto, podemos deshacernos de eso y eso podría simplemente devolver cualquier valor predeterminado. Aquí simplemente tenemos world. Esta es una consulta de GraphQL. Por supuesto, podríamos hacer lo mismo para los resolvers también. Entonces, en lugar de simplemente obtener data todo el tiempo, podríamos ejecutar una mutación aquí y podríamos hacer lo que quisiéramos aquí. Las consultas de GraphQL a menudo obtienen data. Son similares a las solicitudes GET, mientras que una mutación es típicamente como una operación de post put patch delete. Aunque con GraphQL, típicamente solo interfazas sobre post y la consulta es cuando obtienes data, la mutación es cuando quieres cambiar algo.

Podemos escribir lo que queramos aquí y crear una mutación. Se ve muy, muy similar a lo que hicimos antes y puede hacer lo que necesitemos. Así que haremos esto. Hablaremos un poco más sobre las mutaciones más adelante. Pero por ahora, este es un servidor GraphQL muy básico en este punto. Y todo lo que realmente hemos necesitado hacer es esto, eso es todo lo que se necesita. Si abrimos el archivo hello, tenemos dos archivos que crean un servidor GraphQL. No hay nada más que necesites hacer. No necesitas importar un servidor e instanciar ese servidor y luego configurar el despliegue de ese servidor. No tienes que configurar TypeScript. En este punto, tienes un servidor GraphQL que puedes implementar en producción y devuelve el valor que pasas a la consulta hello. Ahora, no es muy parecido a un entorno de producción. Probablemente sea algo que nunca usarías. Ni siquiera es tan avanzado como una lista de tareas pendientes. Pero sí, esto es lo que tenemos.

Bueno, creo que deberíamos pasar a cosas más interesantes porque eso es bastante aburrido. Aquí tenemos esta consulta. Vamos a dejarla ahí. Y a continuación, quiero hablar sobre cómo agregar conectores a GraphBase y poder unir tus propios data también. ¿Qué API deberíamos usar? Tengo mi propia API que uso, que es solo una API de Carrito de Compras. Creo que podríamos usar eso como ejemplo. Y luego te mostraré algunas otras cosas como un headless CMS.

Así que quiero mostrarte de manera muy básica y muy rápida cómo podemos usar un conector para conectar una API de GraphQL. Y es posible que te preguntes por qué haríamos eso. Entonces aquí creemos una nueva consola llamada CartQL porque esa es la API de GraphQL que estamos usando. Luego podemos llamar al conector. Y aquí elegiremos el conector de GraphQL. Le daremos un nombre, por ahora solo lo llamaremos CartQL. Y luego podemos darle algunos valores adicionales. Y aquí pasaremos la URL de esa API. No es importante que sepas cómo funciona esta API. Eso es simplemente lo que estamos usando.

Tenemos una pregunta sobre tener un esquema de tipo basado en gráficos que no es asignable a un tipo de entrada. Es una de las propiedades, ya sabes, está sucediendo en g.query, el nombre es el que se resalta. Esto aquí. Eso me suena como si fuera una mutación que se ha llamado. ¿O estás invocando un enum? Esto es lo que tengo. Parece similar. Parece idéntico. Sí. Se ve bien. ¿Y estás exportando la configuración predeterminada, verdad? De acuerdo. Entonces podría ser algo con el editor. Asegúrate de que esto esté importado. También asegúrate de tener instalada la última versión del SDK. Puedes ejecutar npm install en graph base slash SDK en latest, y traerá la última versión. Solo verifica que lo tengas todo ahí. Vuelve a iniciar el servidor. Entonces sí, la única razón por la que esperaría que haya un problema de tipo. Ni siquiera sé si hay alguna forma de replicarlo. Sí, no estoy seguro de qué podría ser. ¿Estás usando Windows? ¿Estás usando Mac? No es que eso importe realmente, pero me gustaría registrarlo. Mac, de acuerdo. Sí, igual que yo. De acuerdo. Sí, es extraño. Ese error que estás recibiendo, ¿por qué no lo pego en pantalla para que otros lo vean? Este es el error. Tengo un esquema de tipo basado en gráficos. No es asignable a un tipo de entrada. Ciertamente suena como si fuera una mutación aquí, pero obviamente eso no es correcto porque compartiste el esquema. Sí, lo siento por eso. No estoy seguro de qué está pasando ahí. Sí, la última versión debería funcionar con eso. De todos modos, tal vez podamos pasar por alto eso. ¿Qué sucede si comentas esto? ¿El servidor se ejecuta si solo comentas eso? Y solo quiero verificar que tengas graph-based.config.ts dentro de la carpeta graph-based. Y package.json está en la raíz.

No te preocupes. Si lo descubres, avísame. De todos modos, sigamos adelante.

Pero una vez que hemos creado, una vez que nos hemos conectado a una API, debemos decirle a GraphBase que adjunte esto como una data fuente al esquema. Todo lo que necesitamos hacer en este punto es decir, que cartQL es una data fuente para el esquema de GraphBase. Pásalo. Y como el servidor todavía está en ejecución, ha detectado ese cambio. Volvemos aquí y actualizamos. Ahora podemos ver que tenemos una consulta aquí. Esto también es un espacio de nombres, por cierto, que tenemos esta consulta para el carrito. Luego podemos dar un argumento a esto. Así que llamémoslo tscongress. Tsc. Y a partir de esto, podemos obtener el ID. Obtendremos el subtotal, el monto formateado. Tal vez mientras obtenemos los elementos totales, ejecutamos eso. Aquí podemos ver que no tenemos nada. Si actualizamos esta consulta y obtenemos el nombre del artículo y la cantidad, tal vez mientras obtenemos el monto total de la línea y el monto formateado, estamos haciendo una solicitud aquí. Cuando ejecutamos eso, va directamente a esa API a la que nos hemos conectado. Y sí, está pasando por la puerta de enlace de GraphBase, pero esa consulta se proyecta en la otra data fuente. Ahora, eso es interesante, pero ¿por qué es interesante? Bueno, si tomamos esto y si ejecutamos una mutación para hacer lo mismo, pero esta vez agreguemos un artículo al carrito. Y diremos que esto es TSC, y especificaremos un ID de artículo aquí. Le daremos un nombre de prueba. Le daremos un precio de 1,000 centavos. Luego devolveremos el ID. Ejecutaremos esa mutación. Eso ha agregado un artículo al carrito. Si ejecuto esto nuevamente, ahora debería haber tres artículos en el carrito. Entonces, si vuelvo y ejecuto la consulta que teníamos antes, ejecutamos esta consulta que teníamos antes, ahora obtendremos una respuesta que tenemos tres artículos. Luego vemos todos los artículos aquí, y obtenemos un monto total de línea para cada uno de ellos. Podríamos llegar a obtener el monto y el monto formateado para esas líneas para obtener los precios individuales de los artículos. Entonces, una experiencia de carrito de compras muy típica, ¿verdad? Esto es lo que vemos cuando usamos el estado para el carrito de compras, ya sea una API o una dependencia. Eso es lo que obtenemos. Ahora bien, esta es una API, pero vamos a animar las cosas. Ahora, si entramos aquí, voy a agregar a mi archivo env una clave de API. Lo haré fuera de pantalla muy rápidamente. Pero dentro de mi archivo env, acabo de agregar dos variables de entorno, nombre y su valor, y te mostraré cuáles son esos nombres en un segundo. Entonces, si ahora tomo otro conector, y debajo de aquí, me voy a conectar a Contentful. Así que le he dado el nombre de variable Contentful. He usado el conector GraphQL, porque Contentful tiene una API de GraphQL. Luego le doy este nombre Contentful, que es diferente a este de aquí arriba, y luego le doy la URL. Y así es como invoco esa variable de entorno. Tengo una variable de entorno llamada Contentful underscore API underscore URL, y luego en ese archivo de variables de entorno, eso es igual a esa URL. Y luego tenemos los encabezados aquí, y esta es la firma, el formato que Contentful espera, que es este encabezado de autorización de portador, y luego pegamos el valor allí. Por último, solo conectamos nuestra data fuente. Y eso es todo lo que tenemos ahí. Entonces, si volvemos y actualizamos, veremos que ahora tenemos una API, dos API, y luego tenemos esa API que es nuestra propia, esa consulta de saludo que tenemos, que GraphBase resuelve por sí mismo. Pero si abrimos Contentful aquí y vamos a la propiedad, podemos obtener los elementos, y tal vez obtengamos el nombre y la ubicación, la latitud y longitud de eso. Luego lo obtenemos.

Esta es una ubicación que he almacenado en Contentful. Así que ahora, en este punto con GraphQL, podemos hacer muchas cosas. Podemos realizar consultas y mutaciones en múltiples bases de datos o fuentes de datos o APIs utilizando un único punto final de GraphQL. Entonces, si quisiéramos crear una página, digamos, por ejemplo, si quisiéramos agregar elementos a un carrito que tal vez fueran propiedades que quisiéramos comprar o alquilar, podríamos usar una única API para hacer eso, y con GraphBase podemos unirlos, y profundizaremos en eso un poco más adelante.

Pero con esto aquí, ahora podemos echemos un vistazo a esto aquí. Tenemos una colección de propiedades. Tenemos elementos, que es el tipo de propiedad de Contentful. Pero tenemos el nombre y tenemos la ubicación. Imagina una hermosa interfaz de usuario que se muestra en estas ubicaciones. ¿Qué pasa si quisiéramos ver el clima actual? Bueno, tendríamos que llamar a una API de clima, pero podrías estar pensando, bueno, ¿cómo funcionaría eso? Así que tenemos la capacidad con GraphQL de ejecutar múltiples consultas aquí, por lo que podríamos hacer algo donde tenemos una consulta para el clima, y luego pasamos la ubicación, tal vez sea la latitud y longitud. Pero imagina hacer eso para cada ubicación individual. Eso podría llevar bastante tiempo y la experiencia de desarrollo puede que no sea la mejor allí. Así que aquí podemos ver que tenemos una respuesta tanto de Contentful como de nuestro resolvedor local.

Pero ¿qué pasa si pudiéramos, en lugar de crear este resolvedor por separado, qué pasa si pudiéramos expandir el elemento de la colección de propiedades, o el tipo, para devolver un campo llamado clima. Ahora no tenemos este campo de clima en este momento, pero vamos a agregar eso. Entonces, dentro de aquí, debajo de nuestra fuente de datos, vamos a extender esa propiedad. Así que si hacemos g.extend y aquí necesitaremos pasar el nombre del tipo. Así que si volvemos a esto, vamos a ver dentro de la consulta de Contentful. Vamos a bajar a la colección de propiedades. Eso devuelve una colección de propiedades. El elemento es una propiedad de Contentful. Y este es el tipo que queremos devolver o extender. Así que ahora vamos a crear un nuevo campo llamado clima. Podemos darle algunos detalles. Podemos darle esos argumentos similares a los que teníamos antes con el saludo. También podemos configurar el resolvedor aquí. Y luego podemos usar retornos. Así que en este caso, vamos a devolver de nuevo. Tal vez sea un decimal. Sí, vamos a devolver un decimal allí. Y luego llamaremos al resolvedor clima. Entonces, con este archivo, lo guardaremos, y vamos al resolvedor, y crearemos un nuevo archivo que llamaremos weather.ts. Y similar al resolvedor que teníamos antes, simplemente copiaremos y pegaremos eso. Y lo llamaremos resolvedor del clima. Ahora lo que podemos hacer es hacer algo dentro de aquí para devolver la temperatura actual, el clima, para esta API. Ahora no quiero pasar mucho tiempo en esto porque tenemos otras cosas que cubrir. Pero en este punto, podrías implementar una llamada a una API para obtener el clima actual. Y este ejemplo está dentro de nuestra documentación, si quieres seguirlo con ese ejemplo específico. Pero aquí podríamos simplemente devolver, tal vez sean 22.5 grados. Y luego no necesitamos los argumentos aquí. Y luego hacemos eso, guardamos eso, volvemos aquí. Y, ups, necesitaremos hacer una consulta para eso una vez más. Y ahora tenemos este nuevo campo llamado clima. Lo ejecutaremos. Y ahí lo tenemos. Obtenemos ese valor, 22.5, que vuelve. Así que genial. Ahora tenemos algunos datos. Tenemos una respuesta que vuelve. Entonces, imagina que tienes una API que está remota.

Tenemos esta API de Contentful. Pero quieres extenderla con tu propia lógica personalizada. Bueno, acabamos de ver lo fácil que es con unas pocas líneas de código. Así que aquí tenemos g.extend, damos el nombre de nuestro nuevo campo, luego especificamos el tipo del campo y luego el resolvedor weather, el nombre del resolvedor que es weather, y luego simplemente creamos un archivo único que llamamos weather. Y eso es todo lo que necesitamos hacer.

Ahora, si quisieras hacer, tal vez, así que quisieras obtener la latitud y longitud de la ubicación. También podemos hacer eso. Así que por el bien de esto, podríamos hacer algo como hacer una solicitud fetch y aquí podríamos decir que lat es igual a lat y la longitud es igual al valor long aquí. Y esta ubicación es lo que proviene de la propiedad o de la consulta, por lo que si agregamos eso aquí dentro, podemos acceder a estos valores aquí dentro, y para eso es ese argumento raíz o padre.

Así que sí, por favor, haz cualquier pregunta, si nada de esto tiene sentido, o si todo tiene sentido, entonces genial. No preguntes nada, o lo que sea, solo avísame si hay algo en lo que pueda ayudar. Ahora, en este punto, podemos seguir agregando más fuentes de datos. Agreguemos algunas más.

En este punto, hemos integrado APIs remotas y hemos diseñado nuestra propia consulta de GraphQL con nuestros propios datos, pero ¿qué pasa si queremos extender una API que no es una API de GraphQL? Tal vez solo queremos incrustar una API de GraphQL o una API REST y transformar eso en una API de GraphQL y generar GraphQL y hacer todo este tipo de cosas de REST a GraphQL. Bueno, porque existe algo como la especificación de API abierta de GraphQL, eso es una especificación que GraphBase puede leer y luego nuestro sistema, nuestro motor, puede tomar todos esos datos y transformarlos en GraphQL.

Entonces, si traigo este ejemplo y lo recorro muy brevemente, aquí tenemos Stripe, una API muy famosa, muy genial. Una API muy genial. Pero no tienen GraphQL. Lo que tienen es una especificación de API abierta. Podemos tomar esa especificación y enviarla al conector de API abierta, configurar todos los encabezados que necesitamos y luego cualquier transformación. Y con las transformaciones, lo bueno de eso es que podemos decir, okay, quiero excluir ciertos campos. Entonces tal vez solo queremos obtener el campo de usuarios o el campo de clientes o la consulta de pedidos. También podemos extender todo eso y excluir eso, lo siento.

Entonces, con eso, si guardamos eso, necesitaré agregar mi variable de entorno en pantalla completa nuevamente, solo agregar mi variable de entorno a ese archivo .env tan importante. Creo que estamos bien. Sí, así que he agregado eso. Ahora, con esto en funcionamiento, se han detectado los cambios y puedes ver aquí que detectamos esa clave de API de Stripe y la hemos configurado en .env. Ahora podemos usar eso. Así que si volvemos a Google Chrome, ahora deberíamos ver que tenemos una consulta para Stripe. Y todas estas consultas aquí se generaron automáticamente para nosotros en función de la especificación de OpenAPI. Por eso me encantan las especificaciones que podemos leer una y saber cómo se llama el campo y el tipo del campo y la URL y tenemos todas las propiedades de cada campo individual donde podemos hacer lo que necesitamos hacer para transformar todo eso, todo predecible.

Entonces aquí, voy a hacer una consulta para obtener mis clientes de Stripe, así que obtendremos el nombre y tal vez obtengamos el correo electrónico. Realizamos esa solicitud. Luego obtenemos los datos que regresan de esto. Solo necesito admitir algunos más. Ahí vamos. Sí, tenemos una consulta que va a Stripe y está recuperando a todos mis clientes.

Ahora, el concepto que teníamos antes de extender Contentful con un campo personalizado. Digamos que queremos hacer lo mismo para Stripe. Ahora, digamos que queremos obtener el avatar o el gravatar de cada uno de nuestros clientes de Stripe. Ahora, Stripe no tiene un campo llamado gravatar, pero porque estamos usando GraphBase, podemos crear un resolvedor para eso. Para ahorrarnos un poco de tiempo, voy a copiar y pegar el código para hacer que eso suceda y lo recorreremos. Debajo de esa fuente de datos de Stripe, haremos exactamente lo mismo que hicimos antes. Llamaremos a g.extend y esta vez pasaremos el nombre del tipo StripeCustomer, luego llamaremos al campo gravatar y luego para eso, especificaremos que hay algunos argumentos para este campo. Podemos especificar el tamaño, la imagen predeterminada si no existe una imagen, por supuesto, una calificación y el booleano para solo obtener imágenes seguras. Y luego devolvemos una URL que es opcional o nula y luego usamos el archivo gravatar. Y esto aquí, ¿dónde está? enum ref, la calificación. Acabamos de crear un enum de GraphQL aquí. Así que voy a guardar esto.

Pero no quiero crear consultas y mutaciones para los datos que se encuentran en una base de datos. Tal vez si se trata de algo como SQL o MongoDB, podemos generar automáticamente algunas de esas cosas. Bueno, con GraphBase podemos hacerlo. Tenemos un pequeño conjunto de adaptadores de base de datos. Actualmente tenemos MongoDB. También estamos trabajando en adaptadores para Postgres y Neon. Para esto, simplemente llamaremos a Mongo y lo llamaremos conector.mongodb. Le daremos un nombre, simplemente lo llamaremos Mongo. Muy creativo. Luego necesitamos agregar algunas cosas. Agregaremos la clave de API, la URL, la fuente de datos y la base de datos. Ahora, para aquellos que nos siguen ahora o más tarde, esta URL, fuente de datos y base de datos, y la clave de API para Mongo provienen de MongoDB Atlas. La oferta de Atlas que tienen, ya he creado una base de datos y he habilitado la API de datos. Nuestra documentación te guiará a través de esto si no estás familiarizado con eso. Si abro las guías y voy a MongoDB. Publiqué esto hace unos días, y sí, necesitas una base de datos de Mongo con la API de datos habilitada, y puedes obtener estos valores de allí. Eso es MongoDB, cuando vas a su sitio web y te registras, creas una base de datos. Eso es de lo que estoy hablando. Eso es lo que estamos usando aquí. También puedes usar una versión local de MongoDB, y también puedes consultar nuestra documentación para eso, pero para los propósitos de esto, simplemente usaremos la remota. Ahora, lo que esto significa es que luego podemos hacer en el conector de MongoDB es especificar diferentes modelos. Aquí, creemos un modelo para el usuario y luego le daremos algunos campos, tal vez nombre. Diré que este campo de nombre es una cadena, y la edad es del tipo entero. Y tal vez el correo electrónico también sea una cadena. Podríamos usar el correo electrónico aquí también, y esto te dará algunas cosas de validación. Mantengámoslo como una cadena para no salirnos del guion. Pero luego lo único que queda por hacer es adjuntar esa fuente de datos de Mongo al esquema. Aquí hemos especificado un modelo, y esta es una palabra clave nueva. No la hemos usado en ningún otro lugar. Este nombre de usuario funciona con el modelo y el modelo generará una API CRUD para la colección de usuarios. Ahora, si queremos personalizar el nombre de la colección, podemos darle un nombre de usuarios. Entonces, en lugar de usar el modelo de usuario en singular para el nombre de la colección, podemos especificar que queremos el plural usuarios. Ahora, si todo sigue funcionando, que lo está, eso se recargará. Y ahora, si exploramos la base de datos de Mongo, el espacio de nombres de Mongo, ahora obtenemos dos consultas, usuario y colección de usuarios. También obtenemos, dentro de la mutación, dentro de Mongo, obtenemos crear usuario, eliminar y muchas consultas, crear muchos, actualizar y actualizar muchos, también mutaciones. Todo esto se genera automáticamente para nosotros. Y si entramos aquí, miramos los argumentos, abrimos la documentación para eso, podemos ver aquí en los argumentos de entrada que también tenemos todos esos campos diferentes. Y porque no especificamos que estos fueran nulos, todos estos son no nulos o requeridos, no opcionales. Y todo esto se generó automáticamente. Entonces, si volvemos a la consulta, aquí haremos una consulta de GraphQL y diremos, dame los primeros 100 usuarios. Y luego, volviendo a lo que estábamos hablando antes con bordes y nodos, seguimos esa especificación de relay aquí, por lo que generamos los bordes aquí. Entonces podemos obtener el ID, nombre, edad y correo electrónico. ¿Agregué todos esos? Sí. Ejecutamos eso. Eso luego hace una solicitud a la API. Parece que no tenemos un valor de edad, así que podríamos hacer .opcional aquí. Hacemos opcional aquí para estar un poco seguros. Tal vez también agreguemos opcional aquí. No he verificado los datos en MongoDB en unos días, así que podría ser que se haya eliminado, pero ahí lo tienes.

La edad es nula, no había ningún valor, y debido a que se especificó como no nula en un tipo, la API no devolvería un valor nulo. Así que ahí vamos. Obtenemos los datos. Eso proviene de MongoDB.

Entonces, sí, hay un comentario aquí. Esto parece increíblemente poderoso. ¿También tenemos los otros beneficios de traducir la API REST a GraphQL? Almacenamiento en caché. ¿Dónde iría ese ID único de la especificación GraphQL en las implementaciones? Ahora veo tu ID. De acuerdo, genial. Sí, el almacenamiento en caché es un tema interesante del que voy a hablar porque es lo que engloba todo esto y vuelve a nuestro primer comentario en las diapositivas iniciales, que se trata de llevar las fuentes de datos al límite. Lo hacemos utilizando el almacenamiento en caché. Así que creo que eso es una buena transición hacia el almacenamiento en caché, esa pregunta. Así que muchas gracias.

Pero sí, solo para finalizar esto, si quisiéramos crear un nuevo usuario, dentro de aquí, podemos pasar un nuevo nombre y podemos pasar ese valor y luego a partir de eso, podemos obtener el ID insertado. Ejecutamos esta mutación. Inserta un nuevo registro. Hagámoslo. Y lo llamaremos, te agregaremos aquí. Edad, también lo inventaré. Por cierto, no te ofendas. No sé, 30. ¿Es esa una buena edad promedio? Vamos con 25, para no ofender a nadie, y luego el correo electrónico. Digamos en graphql.com. No sé si es un sitio web o .org. Y luego ejecutamos eso y boom, de inmediato, lo tenemos hecho. Volvamos a la consulta que teníamos antes. Ahí vamos. Ahí vamos. Tenemos a mí mismo y tenemos esa segunda entrada que acabamos de crear proveniente de MongoDB. Esto está en MongoDB Atlas. Es algo remoto. Pero podemos hacer todo esto sin necesidad de hacer nada. Todo lo que hicimos para hacer todo eso posible son estas 15 líneas de código. Bastante genial. 15 líneas y nos mudamos al espacio. 15 líneas de código y tenemos una API CRUD completamente funcional con mutaciones por lotes también.

Entonces, ¿cómo sugieres hacer que estos servicios, las consultas GraphQL, estén seguros contra ataques DOS? Eso es posible. Puedes, dentro del resolutor, agregar límites de velocidad. Podría haber una biblioteca para limitar la velocidad. De hecho, tenemos una solución de café dentro de los resolutores que podrías almacenar. Conocemos la dirección IP. Pero GraphBase en sí y nuestra oferta en la nube, tenemos herramientas que permiten configurar todo eso. Ahora mismo, te mostramos lo que la gente está solicitando, cuánto tiempo tardan las solicitudes en las fuentes de datos, etc. Pero queremos dar a los usuarios la capacidad de hacer cosas. Pero podrías hacer algo personalizado.

Sí, la pregunta sobre si todo esto funciona con APIs. No. Al principio, si ves esto más tarde, todo esto también está disponible en nuestra documentación. Pero esta consulta aquí, hola, dentro de aquí, podríamos decir, usuarios es igual a esperar. Hagamos que esto sea una función asíncrona. Prisma.user.findall, no sé cuál es la API.

Pero podríamos importar cosas así. Podríamos hacer SQL sin procesar aquí adentro y luego podríamos devolver esos usuarios aquí adentro. Ahora, recomiendo encarecidamente que si alguien está usando Neon o Mongo, siga el enfoque que he mostrado aquí. En unas pocas semanas, tendremos un conector de Neon estable y un conector de Postgres. Aquí puedes especificar tu Neon DB y luego proporcionar la URL para eso. También tendremos soporte para Postgres. Puedes usar cualquier database Postgres y proporcionar la cadena de conexión también. Y luego, con eso, podrás hacer todo lo que hacías antes usando modelos, etc. Pero eso está por venir. Aún no está disponible.

Sí. ¿Podemos crear conectores personalizados? Los conectores personalizados simplemente serían obviamente a través de esta consulta. Probablemente podrías crear... podrías re-implementar la firma de uno, creo, creando algo como crear usuario y luego podrías usar g.input y especificar el nombre y los campos de entrada. Incluso podrías hacer un tipo de unión para que sea polimórfico. Así que hay cierta flexibilidad. Podrías hacer de esto una unión y en lugar de ser un crear usuario podría ser, ya sabes, crear objeto y luego esta unión tendría un nombre, luego tendría valores, lo siento, los diferentes tipos. Así que podría ser usuario. Podría ser, no sé, en el momento, pero producto, lo que sea. ¿Sabes a lo que me refiero? Es de alguna manera polimórfico. Así que podrías reimplementar la lógica del conector de esa manera supongo. Y luego en el resolutor podrías obtener del argumento el tipo, el nombre del tipo en la consulta. Sí, puedes usar, debería, la única advertencia con estos resolutores es que deben ser compatibles con Edge. Creo que Prisma lo tendrá. Creo que Prisma tiene problemas en el borde así que puede que no sea un ejemplo perfecto pero ciertamente otras bases de datos de borde como Neon, Terso y PlanetScale y todas las demás grandes, funcionarían en este contexto sin ningún problema. También tenemos guías sobre todas esas que mencioné anteriormente.

Muy bien, genial. Lo último que quiero cubrir es cuando entramos aquí y hacemos una solicitud a nuestra database, podemos ver aquí que algunas de estas tomaron un tiempo. Vamos a hacer una solicitud a Stripe también. Obtendremos nuestros clientes una vez más. Obtendremos el correo electrónico y Gravatar y tal vez el nombre. Ahora, esa función de Gravatar debe ejecutarse para cada solicitud y luego tiene que ir a Stripe y obtener los data y luego tiene que hacer todo lo necesario para devolver esos data y podemos ver aquí que tardó más de dos segundos en devolver esos data. Eso no es asombroso. Pero una cosa que puedes hacer es con GraphBase es cuando exportas la configuración predeterminada, puedes configurar reglas para la caché. Entonces podemos pasar un array de diferentes reglas y estas toman propiedades como el tipo, maxAge, mutación de validation scopes y el valor estable para validar. No voy a entrar en todos estos. Nuestra documentation los cubre con un poco más de detalle. Pero con maxAge, lo que podemos decir es durante 60 segundos, cachéalo todo. ¿Y cómo cachéalo todo? Bueno, el tipo raíz es consulta. Así que podemos cachearlo todo durante 60 segundos. Ahora que han pasado esos 60 segundos, la siguiente solicitud tendrá que ir al servidor y traer los data de vuelta. Eso no es genial, y si lo que hemos aprendido de si está obsoleto mientras validamos, si han pasado 60 segundos, si es antiguo por 60 segundos y ha pasado el maxAge, simplemente pasa la versión obsoleta, pero en segundo plano, vuelve a buscar, da al usuario esos data antiguos. Así que también podemos pasar ese valor de 60 segundos aquí. Y luego volveríamos aquí, si queremos actualizar los data para la próxima vez, eso irá al servicio, hará esa solicitud. Y luego, cuando lo ejecutemos por segunda vez, veremos aquí en seis milisegundos, obtuvimos la respuesta de Stripe y Mongo que estaba en la caché. E imagina que esto era múltiples fuentes de data y las estás uniendo y tienes tus propias APIs, los usuarios ya no necesitan saltar por todo el mundo y obtener lo que quieren en seis milisegundos. Claro, esto es localmente, pero si lo implementaras en producción, esto sería de 20, 30 milisegundos, mucho más rápido que si fueras directamente a la database, cada fuente de data individual. Y luego, si haces cosas como lo que he hecho con el resolutor, tiene que ejecutar ese resolutor, etc. Podemos evitar todo eso. Sí. Entonces, el borde está, en el borde, correcto. El almacenamiento en caché del lado del cliente utilizando Apollo Client no se ve afectado y puede permanecer ajeno a todos estos detalles de implementación. Sí, si estás utilizando algo como Apollo Client que tiene almacenamiento en caché en el navegador, eso es genial. Pero si tienes 100 usuarios en la página, seguirán haciendo solicitudes a todas las fuentes de data subyacentes, ¿verdad? Así que solo porque un usuario tenga una caché en su cliente, el siguiente usuario no la tiene. Pero con esto, porque está en caché en el borde o en el servidor, si queremos pensarlo en términos antiguos, cada usuario va a tener una gran experiencia, lo cual es genial. Y también, lo que realmente me encanta de la caché en general es el costo. Ahora es mucho más barato usar las API conectadas, ya no tienes que pagar por toneladas y toneladas de llamadas a la API, porque puedes cachearlas. Por ejemplo, pensemos en un sitio web donde compras cosas. Una página de producto típica probablemente no cambie muy a menudo. Cosas como el inventario, por supuesto, y si está en stock o en oferta pueden cambiar. Pero cosas como la descripción y las imágenes, no tienes que obtenerlas cada vez, así que puedes cachearlas. Entonces, si tu sitio ha sido generado estáticamente, puede obtener datos estáticos de la caché. Entonces, sí, puedes cachear todas esas cosas, lo cual es genial. Sí, también puedes especificar diferentes configuraciones. Así que configuré la caché para absolutamente todo, pero podría decir que quiero cachear el cliente de Stripe durante 60 segundos. También podría agregar otra regla y decir, bueno, voy a cachear el objeto de propiedad de Contentful o la consulta de Contentful durante el tiempo que sea porque no me importa. Ese data no hace nada. Ahora, lo que es aún mejor es que con estas reglas, digamos, por ejemplo, el cliente de Stripe es un ejemplo perfecto aquí porque en este punto, el gateway de GraphBase está configurado con mi propia clave de API de Stripe. Ahora, si implementas esto, obviamente vas a tener acceso a mis cosas, lo cual no es ideal. Entonces, lo que puedes hacer aquí es decir que los encabezados se reenvíen, establecer la autorización, y luego puedes reenviar, no puedo escribir script hoy, un código, luego puedes reenviar el encabezado de autorización de la solicitud. Así que llamémoslo de otra manera para que sea más fácil. Entonces, clave secreta de Stripe. Y luego este valor aquí abajo, eso podría funcionar, puede que no funcione, no lo he probado. Sí, eso funcionó. Entonces vamos a Stripe de nuevo, estamos obteniendo los clientes. Pero mostró que esto no funciona.

Podría funcionar porque se consulta porque está en caché pero ventajas. Sí, consulta incorrecta, pero aún funciona porque está en caché. Pero una vez que ese tiempo ha pasado, esa consulta ya no funcionará porque ese valor no es válido. Ahora, en este punto, ese data se almacena en caché a nivel global. Pero también puedes especificar el alcance con la configuración de las consultas. Tenemos un conjunto limitado de alcances en este momento. Y puedes especificar que sea público. Así que es para todos, todos obtienen el mismo tipo de lectura desde la misma caché o puedes hacerlo en función de la clave de API. Entonces, si usas un token o un encabezado para resolver ese data, podemos averiguarlo y almacenaremos en caché la respuesta específica para una clave de API. Entonces, si haces una consulta para obtener todos los clientes, pero pasas tu propia clave de API, eso se almacenará en caché solo para ti. Y si lo hago, se almacenará en caché solo para mí.

Muchas gracias por los comentarios. Me encantan todas las preguntas. Sí, creo que honestamente, creo que la data disponibilidad y el costo son simplemente asombrosos. Sabes, vuelvo a los días, como que ya no tengo la presentación abierta. Pero me la mostraron al final. Veamos si podemos mostrarla. Me la mostraron al principio. Mira, me mostraron esto al principio, ¿verdad? Tenemos tantas herramientas y APIs que están en todas partes del mundo y están en diferentes regiones. Entonces, terminas teniendo que pagar, tienes que pagar a todos estos proveedores diferentes que ponen tu API y duplican los data en diferentes regiones. Si tienes seis regiones, lo siento, si tienes seis APIs de proveedores y quieres distribuirlos por todo el mundo, sabes, ese costo simplemente se disparará. Es demasiado caro, incluso para aplicaciones que generan millones en ingresos y pueden permitirse esto. No es un costo que creo que deberíamos tener que asumir. Debería haber una mejor manera para esto. Y creo que eso es lo que estamos tratando de resolver. No es la solución perfecta, porque aún habrá una latencia al principio hasta que se almacene en caché, pero con el tiempo, lo que queremos hacer es hacer que podamos ingresar esos data. Así siempre tenemos, ya sabes, estamos leyendo tus data en tiempo real. Abres una conexión con nosotros, y podemos simplemente traer esos data. Entonces, en lugar de hacer solicitudes a tu database, las haces a nosotros, y en segundo plano vamos a la database y nos aseguramos de que todo esté sincronizado. Hay una técnica realmente genial que creo que podríamos adoptar. Eso es todo lo que quería cubrir hoy. Solo dar un recorrido rápido por las cosas. También hay cosas que no he cubierto sobre la autenticación. Otra cosa genial, voy a hablar de ello rápidamente. Puedes configurar la autenticación aquí. Puedes especificar reglas diferentes. Puedes especificar reglas basadas en grupos, propietario, privadas, públicas aquí. Y para los grupos puedes decir, okay, el grupo de administradores, ups, puede obtener data, puede eliminar data, etc. Entonces puedes configurar esas reglas para tus conectores también, lo cual es genial. Y luego, cómo funciona la autenticación es que puedes iniciar sesión en Clerk o Auth0 o cualquier proveedor de autenticación que estés usando, obtener un JWT y usar ese mismo JWT para autenticarte en esta API. No tienes que migrar a tus usuarios a nosotros o cambiar la forma en que manejas el inicio de sesión de tus usuarios. Sí, simplemente puedes usar eso con nosotros. Usa lo que ya tienes con nosotros. Y eso funciona bien, sin problemas. Eso no es lo que estamos tratando de hacer. Cuando se inició GraphQL por primera vez, dimos la opción a las personas de usarlo. Todavía está disponible ahora si quieres usarlo, pero pronto lo vamos a deprecar. Pero también está la opción de tener una database. Que nosotros administramos e implementamos para ti. Pero honestamente, no sé tú, pero no quiero migrar mis data. Como que probablemente llevará a mí y a mi equipo mucho tiempo migrar data. Entonces, sabes, hablamos con nuestros usuarios y les dijimos, hey, ¿qué tal si creamos una API para tus data. Y te permitimos extender tus bases de datos con data que no pertenece a tu database. Y eso parece ser algo bastante genial para ser un ajuste de producto. Entonces, sí, eso es todo lo que tuve tiempo de cubrir hoy. Avísame si hay alguna otra pregunta. Puedes contactarme en Twitter. Agradecería mucho que te unas a Discord o al menos me menciones en Twitter. Si vamos a Twitter aquí, soy Notrap, que es Barton al revés. Si quieres ver más cosas geniales como esta y también voy a hablar de esto el próximo mes, avísame. Házmelo saber en Twitter si tienes alguna pregunta. Sí. Principalmente hablo sobre GraphQL y bases de datos y APIs. Así que si te interesa ese tipo de cosas y quieres charlar más, vamos a pasar el rato. Pero por hoy, creo que si no hay más preguntas, creo que lo dejaremos aquí. Genial. Gracias a ti también. Muchas gracias por venir. Gracias a todos. Y sí. Nos vemos por ahí.