Unificar Fuentes de Datos con GraphQL en el borde

Hola a todos, soy Jamie. Estoy muy emocionado de estar aquí hoy en TS Congress y espero que todos estén pasando un tiempo fantástico. Hasta ahora, hay tantos oradores increíbles y charlas programadas. Estoy realmente emocionado de ver eso y ponerme al día.

Pero obviamente, después de esta charla, solo tenemos unos minutos juntos hoy para revisar algunas diapositivas y hacer una demostración. Así que creo que deberíamos sumergirnos en el tema de unificar las fuentes de datos con GraphQL.

Ahora, si estás construyendo una API, no importa si esa API es REST o si es GraphQL. Es bastante difícil. Sí, es fácil instalar una dependencia, crear algunas definiciones de tipos con GraphQL y luego crear algunos resolvers y desplegarlo. Es fácil hacer eso. Pero hay muchas otras cosas que debes considerar al construir algo escalable que deseas desplegar en producción, en el borde, esperemos, para que tus usuarios lo usen y consuman.

Y esta lista que ves aquí es solo una pequeña muestra de algunas de las preocupaciones que debes tener en cuenta al construir algo escalable y mantenible en producción. Pero creo que el mayor problema hoy en día, es un gran beneficio tenerlo. Pero el mayor problema es que hoy en día tenemos tantas fuentes de datos diferentes que todos tenemos que descubrir cómo usar todas las APIs y SDKs. Bueno, todas son diferentes también. Hay una curva de aprendizaje diferente. Hay diferentes tipos de documentación. Algunas están más documentadas que otras. Algunas no llevan tiempo en absoluto comenzar y otras llevan días para entender. Y debido a que ahora estamos utilizando tantos de estos servicios para entregar nuestros productos finales, a menudo puede llevar mucho tiempo hacer eso.

Creo que la aplicación de tareas más simple que todos solíamos hacer y construir cuando comenzamos con algo, creo que en el mundo de hoy, con todas estas diferentes fuentes de datos, creo que hay tantas implementaciones diferentes de eso ahora, donde tal vez creas una aplicación de tareas que cuando agregas una tarea, te envía una notificación a través de Slack o correo electrónico o SMS. Así que hay tres servicios. Y tal vez cuando agregas algo o eliminas algo o marcas algo o desmarcas algo, tal vez eso se agrega a los espacios libres en tu calendario para que realmente puedas encontrar tiempo para hacer estas tareas. Así que sí, hay muchas cosas que considerar al construir aplicaciones con todas estas diferentes fuentes de datos. Y es genial que tengamos esta flexibilidad. Pero sí, como digo, el inconveniente es que algunas de estas APIs tienen una mejor documentación. Algunas no la tienen. Pero lo más importante, creo, es que todos los diferentes servicios que usamos hoy en día no están realmente enfocados en dónde podría residir los datos porque saben que pueden confiar en que alguien use algún caché o un generador de sitios estáticos o algo así. Así que la mayoría de estos se despliegan en una sola región. Pero, por supuesto, si queremos usar todos estos diferentes servicios, esos datos realmente deberían estar en el borde más cercano al usuario para que puedas obtener la mejor experiencia al usar tu aplicación que obviamente creas usando TypeScript.

Y creo que todas estas APIs se implementan en una sola región. Y obviamente puedes pagar para implementarlas en otras regiones. Pero creo que eso es algo que todos deberíamos tener la flexibilidad de hacer y configurar por nuestra cuenta. Porque hay tantos servicios que no te brindan esa flexibilidad cuando realmente la deseas. Y tal vez si lo obtienes de un proveedor de servicios, te cobrarán mucho más por hacerlo. Así que eso es lo que estamos tratando de resolver en GraphBase.

Y permitimos a los desarrolladores conectarse a cualquier tipo de database, tal vez un almacén o una aplicación de comercio como Shopify. Si tienes un producto en Shopify al que deseas agregar más productos o reseñas. Es posible que desees obtener esas reseñas de una API diferente. Tal vez tengas algún contenido en HiGraph o Contentful o Sanity que deseas agregar a estas páginas de productos. Bueno, te brindamos la capacidad de agregar fuentes de datos, ampliarlas y agregar tu propio código personalizado y hacer otras cosas. Así que estamos en una misión para hacer eso, para crear una única API de GraphQL a la que puedas agregar diferentes fuentes de datos y también tus diferentes frontends. Y con todo esto, tienes una seguridad de tipo completa en el backend, una seguridad de tipo completa en el frontend con esa API unificada de GraphQL. Y hay tantas herramientas geniales para hacer eso.

Y lo que hace GraphBase es, obviamente, tener esta API GraphQL unificada donde todas estas fuentes de datos viven. Y además, puedes agregar cosas como Autenticación. Puedes utilizar tu propio proveedor de autenticación como Click o Auth0 y luego puedes decir que este usuario puede actualizar pero no puede eliminar, o pueden leer pero no escribir. Todo eso se puede configurar dentro de la configuración. Pero la gestión real de usuarios ocurre en otro lugar. Básicamente, puedes utilizar tus propios usuarios para utilizar la API y las bases de datos conectadas.

Y además de eso, como mencionamos anteriormente, es importante tener los datos disponibles en el borde, cerca del usuario. Bueno, también hacemos eso con el almacenamiento en caché en el borde. Eso está integrado en todos los proyectos y puedes aprovecharlo. Luego, cuando implementes esto en producción, si abres una rama en GitHub, automáticamente te crearemos una URL de vista previa a la que estás muy acostumbrado. Sin duda, con cosas como Vercel y Netlify, te dan esa URL inmutable que puedes utilizar. Hacemos lo mismo para GraphQL. Te daremos ese nuevo punto de conexión de la API para que no tengas que pensar en cómo construirlo tú mismo. Eso viene incluido, de serie. También tenemos otros productos como búsqueda y análisis, para que puedas obtener una visión completa de lo que está sucediendo en tu proyecto. Y como mencioné antes, esto funciona con cualquier cosa que estés utilizando actualmente. Donde sea que puedas hacer una solicitud fetch, puedes usar GraphBase. Pero lo importante que quiero destacar es que GraphQL y TypeScript funcionan muy bien juntos debido al sistema de tipos. Un sistema de tipos sólido de GraphQL se puede utilizar con herramientas como el generador de código de GraphQL para generar todos los tipos de TypeScript para todos tus tipos de GraphQL, ya sean consultas, mutaciones o si tienen entradas y argumentos, algunos requeridos y otros opcionales. El generador de código puede crear algo en TypeScript que se ajuste a eso. Entonces, cuando estás utilizando GraphBase y creando tus propios resolutores personalizados, puedes utilizar todo ese código generado para crear algo que sea completamente seguro en cuanto a tipos desde el backend hasta el frontend, lo cual creo que es realmente poderoso.

Pero el tema que realmente quiero cubrir hoy y mostrar en la próxima demostración es cuando comenzamos a construir GraphBase, teníamos una única SDL de GraphQL como configuración. Aquí a la izquierda puedes ver un esquema. Luego tenemos esta directiva personalizada llamada auth con la que configurarías todos tus diferentes proveedores de autenticación. Este OpenIDConnectProvider podría ser algo como clerk, o podría ser auth0 u otra cosa. Puedes agregarlo como proveedor de autenticación. Luego puedes especificar una lista de reglas. Aquí solo tenemos una regla, que es permitir privado. Pero eso agregaría algunas reglas a tu backend para permitir solo solicitudes autenticadas. A continuación, tenemos esta etiqueta GraphQL, que define un espacio de nombres, la URL de la tienda Shopify o de la tienda Contentful. Y también tenemos algunos encabezados.

Aquí tenemos un encabezado personalizado de Shopify. Si lo usas con Shopify, si lo usas con Contentful, obviamente puedes pasar diferentes encabezados. Y luego esos se agregarían cuando hagas ese tipo de solicitud a los diferentes proveedores.

Entonces, sí, este es el SDL que las personas tuvieron que usar durante mucho tiempo. Y es fantástico. Todavía lo uso hoy en día. También uso la nueva configuración de TypeScript, pero el SDL era realmente agradable. Pero lo que no les daba a los desarrolladores eran pistas sobre lo que estaba sucediendo con toda la configuración y las opciones. No obtenías ninguna ayuda de TypeScript o del editor de código cuando configurabas los backends con SDL. Por eso, cuando hablamos con la comunidad, notamos que muchas personas estaban buscando una forma de crear algo que fuera seguro en cuanto a tipos.

Entonces creamos el SDK de GraphBase. El equipo propuso una idea. Hablamos con la comunidad y dijeron: `Wow, esto es genial. ¿Cómo puedo usar esto?` Así que comenzamos a construir el SDK, que te permite importar cosas como autenticación, configuración, conector y esquema. Y luego puedes crear modelos a partir de eso. Luego puedes conectar cosas. Y mientras escribes, puedes aprovechar al máximo TypeScript para asegurarte de que estás pasando una cadena donde se debe invocar una cadena, un entero, etc. Y cosas como la API de encabezados, nos aseguramos de que puedas personalizar y especificar el tipo correcto de claves y valores allí. Y nadie los va a arruinar. Así que obtienes esa seguridad de tipo completa, que también nos encanta. Gracias a TypeScript.

Y creo que lo otro cuando estás construyendo consultas y resolutores de GraphQL que son personalizados para ti. Entonces, estás construyendo estos dentro de GraphBase, puedes configurar todos los diferentes argumentos que tienen. Y si hay algún campo opcional, puedes declararlo aquí dentro. Y TypeScript te ayuda a generar automáticamente ese SDL. Pero sí, quiero hacer una demostración ahora. Ahora abriremos nuestro editor de código. Imagina que esta era tu aplicación frontend y querías crear un backend para tu frontend. Puedes usar la CLI de GraphBase para inicializar un nuevo proyecto. Y luego, por supuesto, queremos usar TypeScript como opción de configuración.

Así que nos encanta esta experiencia ahora, y creemos que a nuestros desarrolladores también les encanta. Nos dicen que sí. Y estamos realmente emocionados de expandir este patrón de construcción de nuestra API.

Así que empecemos creando una consulta aquí. Tenemos algunos argumentos opcionales. Ahora vamos al archivo que tenemos, hello.ts. Aquí tenemos una función de TypeScript. Podemos importar SDK y lo que sea aquí dentro, pero esto es TypeScript. Podemos crear un resolvedor de TypeScript que luego implementaremos en el edge. Creo que ahora, con este resolvedor, deberíamos iniciar el servidor de GraphQL, y luego, si vamos al puerto 4,000, podemos iniciar Pathfinder.

En este esquema que vemos aquí, todo se generó a partir de esa configuración de TypeScript. Así que no tuvimos que preocuparnos por escribir GraphQL SDL. Pudimos usar TypeScript y olvidarnos de que necesitas conocer GraphQL para construir un backend. Si no lo conoces, puedes usar TypeScript para construir estos backends.

Así que a medida que ejecutamos el siguiente paso ahora, podemos crear otra mutación para registrarnos en un evento, tal vez algo como esto. Luego podemos definir algunas cosas como enums e inputs y una mutación, y ahora tenemos un archivo que acepta algunos parámetros. Todo esto que tenemos aquí es seguro en cuanto a tipos, por lo que puedes trabajar con TypeScript y GraphBase para crear estos backends, y no tienes que esperar hasta que inicies el servidor para encontrar errores. Te lo diremos si hay algo mal antes de que llegues allí. Y como puedes ver, el esquema de GraphQL se ha actualizado automáticamente utilizando esa configuración de TypeScript que se convirtió para crear esta API de GraphQL que luego puedes usar para tu frontend.

Ejecutemos una mutación aquí con GraphQL. Nos registraremos para el evento. Podemos pasar nuestro nombre y nuestro estado aquí, que es un enum en GraphQL, y podemos enviar diferentes valores de enum si queremos. Y luego, cuando ejecutemos esa operación aquí, nos devolverá los datos. Así que básicamente es una consulta y mutación personalizada de GraphQL utilizando TypeScript que se configuró usando TypeScript en lugar de nuestro repositorio de GraphBase. A continuación, podemos hacer cosas como conectar Stripe utilizando el conector de la API abierta. Y aquí, gracias a TypeScript, sabemos exactamente qué necesitamos pasar, cosas como encabezados, cuál es la clave, qué valor puede ser, y lo mismo con las transformaciones. Podemos transformar el esquema para excluir ciertos campos, consultas y mutaciones.

Y nuevamente, gracias a TypeScript, obtenemos toda esta ayuda. Antes, cuando usábamos un SDL, ninguno de nuestros usuarios podía hacer eso solo dentro del editor de código. Siempre tenían que consultar la documentación para ver qué podían y qué no podían hacer. Eso llevaba mucho tiempo y la gente no estaba implementando y construyendo aplicaciones más rápido. Pero creo que ahora, con TypeScript, lo están haciendo. Es fantástico.

Entonces, con ese OpenAPIConnector agregado y con el servidor en ejecución, obtenemos toda la API de Stripe aquí en GraphQL gracias a la especificación de OpenAPI. Tomamos eso y lo transformamos en GraphQL. Y los usuarios de GraphBase que quieran construir estos backends no tienen que preocuparse por aprender GraphQL realmente desde el punto de vista del servidor. Nosotros abstraemos toda esa complejidad por ti. Y cosas como pasar encabezados aquí, podemos ver que los enviamos desde el cliente al servicio subyacente, en este caso es Stripe, y lo actualizamos. Y cuando haces una solicitud desde el frontend, simplemente la pasamos directamente a Stripe, lo cual es genial. Y hay cosas como el registro para que puedas profundizar y averiguar exactamente qué está sucediendo si algo sale mal, en lugar de hacerlo en tu resolvedor.

A continuación, vamos a extender la API de Stripe. Aquí tenemos un cliente de Stripe, el cliente de Stripe es el tipo en GraphQL para el cliente de Stripe, pero los usuarios no tienen un campo Gravatar. Así que creo que deberíamos agregar uno. Aquí hay un código personalizado dentro de nuestro resolvedor que está obteniendo el correo electrónico de ese cliente de Stripe, y luego está creando esa URL de Gravatar, y luego simplemente va a devolver una cadena. Así que ahora, con eso en funcionamiento, si vamos a Pathfinder y cerramos la pestaña de encabezados, ahora deberíamos poder invocar ese campo Gravatar que no existía antes. Eso no existe en Stripe, pero hemos podido extender la API de Stripe con GraphBase usando TypeScript. Ahora podemos pasar un valor diferente en los argumentos aquí, y podemos obtener un enlace diferente para obtener un tamaño de imagen diferente. Así que eso ha sido extender Stripe con GraphBase y con TypeScript, y todo lo que realmente tuvimos que hacer fue configurar cómo se veía eso usando el SDK y luego escribir ese código. Y por último, veremos el almacenamiento en caché, donde puedes configurar diferentes reglas. Así que aquí tenemos el cliente de Stripe. No queremos almacenar en caché nada más excepto nuestro cliente de Stripe porque generar esa URL para la imagen de Gravatar, bueno, eso podría llevar un poco más de tiempo. No queremos esperar por eso, así que vamos a almacenar en caché esa respuesta de URL para que podamos configurar a nivel de tipo, a nivel de campo, lo que quieras. Puedes configurarlo con GraphBase, y luego cuando implementes eso en el borde y hagas una consulta, eso se almacenará en caché. Así que dentro de aquí, esto es cuando el proyecto se implementa con GraphBase. Podemos abrir ese proyecto dentro del panel de control. Y aquí podemos ver que no hemos pasado ese encabezado así que nuestra API está protegida. Ahora, si pasamos el encabezado de autorización para Stripe, esta es nuestra clave secreta con Stripe, ahora ejecutamos esa operación y será exitosa y obtendremos esa URL de Gravatar. Pero, si abrimos el historial aquí, podemos ver que tenemos un fallo en la caché. Ahora, si ejecutamos eso nuevamente, deberíamos obtener un acierto en la caché y podemos ver la diferencia en el tiempo aquí. El tiempo de respuesta ha disminuido significativamente gracias a esa caché que está ocurriendo en el borde. Así que esto ha sido un campo que extiende una API. Pero imagina todas las diferentes fuentes de datos que usas, al llevar eso a una API unificada de GraphQL puedes ahorrar considerablemente tiempo y costos para construir aplicaciones. Así que espero que esto haya sido interesante. Creemos que los desarrolladores pueden construir backends realmente geniales con GraphBase y aún pueden usar TypeScript para crear código personalizado donde lo deseen dentro de esos resolvedores personalizados. Pero luego, para configurar todo esto, no necesitas aprender GraphQL en el lado del servidor. Solo puedes usar esa configuración de TypeScript y el SDK para construir el backend por ti, lo cual es bastante poderoso. Y por eso amamos TypeScript. Así que si estás interesado en aprender más sobre esto, puedes ir a graphbase.com. Y si tienes alguna pregunta, no dudes en contactarme en Twitter. Estoy en Notrab. Eso es simplemente bottom al revés si alguien se pregunta. Estoy encantado de responder cualquier cosa sobre graph base y GraphQL allí. Así que muchas gracias por tenerme hoy.