Construyendo APIs GraphQL sin servidor en tiempo real en AWS con TypeScript y CDK

Hemos creado un nuevo sitio web para que explores el mundo de JavaScript. Estamos ofreciendo artículos gratuitos, videos, cursos y tutoriales para ayudarte a aprender todo sobre React. Haz clic en el enlace de la descripción para obtener más información sobre todos los nuevos cursos de React.js. También hemos creado una nueva lista de reproducción para que la revises. Hemos agregado muchos cursos nuevos y también ofreceremos artículos gratuitos en la web y en dispositivos móviles en el futuro. Haz clic en el enlace de la descripción para obtener más información sobre todos los otros cursos que hemos creado. Haz clic en el enlace de la descripción para obtener más información sobre todos los otros cursos que hemos creado.

De acuerdo, hola a todos y muchas gracias por asistir a mi charla hoy. Estoy muy emocionado de hablar sobre este tema porque es algo que he estado usando mucho últimamente y es realmente poderoso. Voy a hablar sobre la creación de APIs GraphQL sin servidor en tiempo real con TypeScript, AppSync y CDK. Mi nombre es Nader Dabit, soy un Defensor Principal de Desarrolladores y soy desarrollador de front-end y móvil de profesión. Recientemente, he estado trabajando con AWS y servicios de backend durante los últimos años. Últimamente, me he estado enfocando en la creación de aplicaciones full-stack en la nube y sin servidor. Así que vamos a empezar porque tenemos mucho que cubrir.

Voy a hablar sobre algunas cosas y todas están relacionadas entre sí. Primero, comenzaremos con una introducción a GraphQL. Luego, hablaremos sobre AWS AppSync y Manage GraphQL Service. Después, haremos una breve introducción a CDK. Luego, hablaremos sobre cómo todos estos componentes se relacionan entre sí, AppSync, CDK y GraphQL. Después, realizaré una demostración de codificación en vivo. Creo que la demostración de codificación en vivo te mostrará cómo funciona todo esto mejor que cualquier presentación. Pero espero que al poner todo esto junto te sea realmente útil y aprendas algo.

Entonces, hablemos un poco sobre GraphQL. Si buscas en Internet y encuentras la definición de GraphQL, podrías ver algo como esto. Un lenguaje de consulta para tu API. Esto no dice mucho. Vamos a profundizar un poco más. Con GraphQL, tienes tu, casi como un menú de tus datos, que es tu esquema GraphQL. El esquema tiene todos los diferentes tipos de datos, que son básicamente tipos, y todas las operaciones contra esos tipos. Por ejemplo, puedes tener una aplicación de tareas pendientes. Podrías pensar en algo como un tipo de tarea pendiente. Y luego, podrías tener operaciones para crear, leer, actualizar y eliminar tus tareas pendientes. Todo eso se define en tu esquema. Y una vez que hayas implementado tu API, y hablaremos un poco más sobre eso en un momento, simplemente puedes solicitar los datos que deseas. Esto es algo que probablemente hayas escuchado antes, si alguna vez has investigado sobre GraphQL, es que una de las cosas realmente poderosas es que tienes la capacidad de construir APIs con una latencia mucho menor y más controladas que cuando trabajas con puntos finales REST porque tienes mucho más control sobre los datos que se envían de ida y vuelta a través de la red, y luego recibes tus datos de respuesta devueltos en JSON.

Entonces, una API GraphQL está compuesta por tres partes principales. Tienes tu esquema, del que hablaremos en un momento.

Profundizaremos un poco más en un momento. Tienes tus resolvers y luego tienes tus fuentes de datos. Entonces, el esquema es donde residen todas tus declaraciones de datos. Entonces, nuevamente, para una aplicación de tareas pendientes, podrías tener un tipo de tarea pendiente. Y luego, para operar con ese tipo de tarea pendiente, es posible que necesites definir algunas operaciones. Aquí, podrías tener una forma de obtener una sola tarea pendiente por ID. Podrías tener una forma de crear una nueva tarea pendiente utilizando una operación de crear tarea pendiente. Y estas se definen en consultas, mutaciones, y también tenemos un nuevo tipo que es único en GraphQL llamado suscripción, y hablaremos de los tres en un momento.

Entonces, una vez que hayas definido tu esquema, tendrás tus data sources. Y las data sources son de donde provienen los data para estas operaciones, y luego recibirás los data devueltos en uno de los tipos que has definido en tu esquema. Y la forma en que se manejan esas operaciones generalmente se hace en un resolvedor. Y el resolvedor es básicamente solo una función o algún tipo de código que asigna la operación de GraphQL a una data source. Y esto es un detalle de implementación para ti como desarrollador si estás construyendo tu propia API, esto dependerá de cómo lo escribas. Muchos de los frameworks tienen formas un poco más definidas de hacer esto. Y si estás trabajando con GraphQL como un servicio, como AppSync, también tienen sus propias opiniones.

Entonces, una fuente de datos puede ser una database, una función que está fuera del propio servicio principal o un punto final HTTP para incorporar una architecture de microservicios en una API de GraphQL.

Hablemos ahora de la parte de recuperación de datos de GraphQL, que es realmente interesante. Con GraphQL, es posible que estés familiarizado con Rust, por lo que creo que es muy conveniente e interesante comparar los dos, GraphQL versus Rust. Con GraphQL, tienes esta idea de consultas, mutaciones y suscripciones, y se mapean muy bien a cosas que hemos hecho en el mundo de Rust, como mapear a los verbos HTTP con los que trabajamos. Entonces, cuando necesitas leer algunos datos, como obtener o listar una lista de elementos, utilizarás una consulta de GraphQL. Si vas a actualizar, crear o eliminar algo, normalmente utilizarás una mutación, y si necesitas algún tipo de aspecto en tiempo real en tu API, utilizarás suscripciones.

Echemos un vistazo a una tabla de verbos de GraphQL versus Rust. Nuevamente, mapear una solicitud Get tiene mucho sentido con una consulta de GraphQL. Obtener un elemento por ID o obtener una lista de elementos normalmente será una consulta de GraphQL. Y luego, las operaciones de post, put, delete o patch serán mutaciones de GraphQL. Dicho esto, veamos cómo GraphQL devuelve los datos que has solicitado, como mencionamos hace un momento. En una consulta, puedes decir, `Tenemos este tipo de tarea en GraphQL y tiene cuatro campos. Tiene un ID, un nombre y un valor de createdAt o campos`. Y en esta solicitud, queremos obtener los cuatro campos, así que está bien. Pero también puedes decir que solo quieres obtener un subconjunto o una selección más pequeña de estos campos, y esto seguirá funcionando. No tienes que hacer ninguna actualización en tu backend. La forma en que está construido GraphQL, la forma en que se crean estas consultas, solo obtienes los datos que has solicitado. Entonces, si alguna vez has trabajado en la construcción de diferentes tipos de aplicaciones de cliente para un solo backend en el mundo moderno, es posible que tengas una aplicación web, una aplicación móvil, una aplicación de escritorio que también puede tener una aplicación para Apple Watch o incluso una aplicación para automóviles en el futuro, nunca se sabe. Tener GraphQL como fuente de datos te permite tener mucho más control sobre el acceso a tus datos sin tener que cambiar mucho código en tu backend una vez que se completa la implementación.

A continuación, hablemos de las suscripciones de GraphQL, que son el aspecto en tiempo real de GraphQL. Las suscripciones de GraphQL permiten la comunicación en tiempo real entre un cliente y una API. Las suscripciones se basan en eventos. Entonces, cuando creas, actualizas o eliminas un elemento, es posible que puedas suscribirte a ese evento. Normalmente, una suscripción puede tener un nombre como onCreate, onUpdate o onDelete. Por ejemplo, para una aplicación de tareas, podrías tener onCreateTask, onUpdateTask, etc. Las suscripciones suelen ser una conexión bidireccional. Por lo tanto, debes tener una forma de enviar la actualización y luego recibir la actualización de vuelta en el cliente. Muchas veces, te preguntarán cómo implementar las suscripciones de GraphQL. Si estás utilizando un servicio como Hasura o AppSync, o cualquiera de estos servicios de GraphQL, esto se encargará de ti. Pero si estás construyendo tu propia API, normalmente tendrás que tomar la decisión entre servidores y eventos o websockets.

Creo que muchas veces ves que las APIs de GraphQL se construyen utilizando websockets. Entonces, nuevamente, muy similar a una consulta de GraphQL donde solicitas los datos que deseas y solo obtienes esos datos, también puedes suscribirte a subconjuntos de datos. Entonces, aunque nuestro tipo de tarea tiene cuatro campos diferentes, podemos hacer suscripciones y devolver solo un subconjunto de esos campos. Digamos que solo estamos interesados en el ID, el nombre y el valor completado, crearemos una suscripción y solo recibiremos esos datos a los que estamos suscritos. Esa es una breve descripción general de GraphQL.

Hablemos ahora sobre AppSync, y luego hablaremos sobre CDK y después haremos una demostración en vivo. AppSync es un servicio de GraphQL administrado, y está construido utilizando una infraestructura realmente escalable en AWS. AppSync proporciona una capa de API consistente para cualquier servicio de AWS o cualquier fuente de datos, y estas fuentes de datos no tienen que estar en AWS, pueden estar en cualquier lugar siempre y cuando tengan algún tipo de acceso HTTP o algún tipo de acceso a tu centro de datos, que también está disponible.

Tenemos funciones de seguridad empresariales incorporadas. Si necesitas tener tipos de autorización únicos o múltiples para un acceso público y privado o una combinación de ambos, lo tenemos incorporado. Tenemos IAM, tenemos OIDC para utilizar tu propio proveedor de autenticación. Si estás utilizando algo como Auth0 o Octa, puedes usar OIDC. Tenemos Cognito para un servicio de autenticación administrado, y luego tenemos claves de API para acceso público. Y una de las cosas realmente interesantes de AppSync es lo fácil que es agregar una suscripción de GraphQL. Vamos a ver eso en código en un momento. Pero para cualquier mutación, las suscripciones ya están incorporadas en el servicio. Todo lo que necesitas hacer es agregar una línea adicional de código, y puedes suscribirte a cualquier tipo, pero también a cualquier subconjunto de ese tipo. Por ejemplo, puedes pensar en una aplicación de chat donde tienes mensajes. También puedes pasar argumentos, hasta cinco argumentos diferentes, para suscribirte solo a las actualizaciones de una sala de chat, utilizando el ID de la sala de chat.

También construimos y mantenemos nuestros propios SDK para todos estos servicios de AWS, incluido AppSync. Puedes usar algo como Urql o Apollo. Pero tenemos nuestros propios SDK que administran muchas cosas, como los encabezados de autorización. Y tenemos SDK y bibliotecas para web, iOS, Android, React Native y Flutter.

Y ahora hablemos de CDK por un momento. CDK es la abreviatura de Cloud Development Kit. Y CDK es básicamente una nueva forma de escribir infraestructura como código. Y cuando digo nueva, es algo así como un poco más de dos años. Así que no es tan nuevo, pero sigue siendo bastante nuevo. Y puedes hacer esto. Es muy diferente a cualquier infraestructura como código que hayamos visto en el pasado, porque en lugar de usar algún tipo de archivo de configuración como JSON o YAML, estás utilizando TypeScript, JavaScript, Python, o cualquier lenguaje de programación que prefieras. CDK inicialmente solo admitía AWS, pero ahora admite otros proveedores de nube, incluido Azure. Y está ganando mucha popularidad. Muchos usuarios de Amplify que construyen su infraestructura utilizan CDK como proveedor de CloudFormation, o pueden usar una combinación de Amplify y CDK. Y luego utilizan las bibliotecas de cliente de Amplify para conectarse. La inicialización de un nuevo proyecto de CDK se ve así.

Solo necesitas instalar la CLI de CDK, y luego inicializar un nuevo proyecto y estarás listo para comenzar. Luego puedes comenzar a agregar características adicionales desde el boilerplate proporcionado. Vamos a partir de un proyecto base y veremos cómo funciona.

Entonces, AppSync con CDK. Lo que normalmente harás es crear tu nuevo proyecto de CDK, tal como te mostramos hace un momento, CDK Init. Instalarás los paquetes NPM que necesites, cualquier paquete CDK usando NPM. Por ejemplo, para AppSync, necesitarás instalar el paquete CDK de AppSync. Y tal vez también necesites instalar otras fuentes de datos como Lambda, DynamoDB para las bases de datos con las que interactúes desde CDK. Luego crearás y configurarás la API y el código. Le darás un nombre a la API. Establecerás tu esquema GraphQL, y luego configurarás la autorización base. En la API que vamos a construir, configuraremos la autorización base como pública. Luego agregarás fuentes de datos y resolvers a esas fuentes de datos. Por ejemplo, podrías decir, `He creado esta API. Necesito tener una base de datos NoSQL. Necesito una base de datos SQL. Y luego necesito tener una forma de mapear mis resolvers para los tipos, los campos y las operaciones de mi esquema a esas fuentes de datos. Y luego definirás todo esto realmente en código. Y hoy trabajaremos con TypeScript.

Creo que lo más interesante, sin embargo, es la demostración en vivo porque vamos a partir desde cero construyendo esto. Así que lo que voy a hacer es entrar en un proyecto que he creado aquí. Esta es una aplicación de CDK realmente vacía. Voy a abrir esto. Y en el directorio lib, tenemos el punto de entrada para la aplicación de CDK. Aquí es donde vamos a escribir nuestro código. Y si vamos a package.JSON, veremos que he instalado tres dependencias. AppSync para CDK, DynamoDB, que es una base de datos NoSQL y AWS Lambda. Usando todas estas cosas, construiremos una API en solo un par de minutos. Así que lo primero que me gustaría hacer es importar mis dependencias. Voy a importar CDK, AppSync, DynamoDB y Lambda.

Y vamos a utilizar eso para crear nuestra API. A continuación, vamos a crear la referencia de la API utilizando el constructo de AppSync. Y le daremos un nombre a la API. El nombre de la API será CDK Notes AppSync API, y lo llamaremos como React Summit o algo así. Daremos una ubicación para el esquema de GraphQL. Esto estará en GraphQL/schema/schema.GraphQL, que crearemos en un momento.

Luego configuraremos una configuración de autorización predeterminada. Y en nuestro caso, solo utilizaremos una clave de API. Así que la configuramos aquí y luego establecemos una fecha de vencimiento, que será dentro de 365 días a partir de ahora. Y si necesitáramos varios tipos de autorización, podríamos haberlo hecho aquí. Pero no lo haremos. Luego, habilitamos x-ray, porque x-ray es básicamente un sistema de registro muy sofisticado que podemos utilizar para un registro adicional con fines de depuración.

Lo siguiente que queremos hacer es crear nuestro esquema de GraphQL. Así que voy a crear una carpeta aquí y un archivo schema.GraphQL. Y aquí vamos a crear nuestro esquema. El esquema que vamos a crear es para una aplicación de notas. Tenemos un tipo de nota. Tenemos una consulta para listar notas. Tenemos una mutación para crear notas. Y luego tenemos la parte en tiempo real, que es la suscripción para la creación de notas. Así que vamos a decir que queremos adjuntar la directiva AWS_subscribe a esto. Y esto es lo que agrega la funcionalidad en tiempo real. Así que si miramos el esquema y eliminamos esto, todo esto es solo GraphQL básico. Esta directiva aquí es específica de AppSync. Pero esto es todo lo que necesitas adjuntar a cualquier suscripción para establecer una matriz de mutaciones para que se active la suscripción. No se necesita código adicional. Así que vamos a decir que queremos pasar una matriz, pero el único elemento que nos interesa es crear una nota. Queremos suscribirnos a ese evento. Y luego se creará la suscripción on create note para nosotros. Así que voy a cerrar eso.

Y lo que queremos hacer ahora es crear una función Lambda. Y la función Lambda será donde se encuentre nuestra lógica de negocio o nuestra lógica para interactuar con la base de datos. Así que vamos a seguir adelante y decir que estamos creando una función Lambda. La estamos referenciando como notes Lambda. Estamos diciendo nueva función Lambda. Y podría minimizar esto aquí para tener una mejor vista del código. Estamos configurando un tiempo de ejecución. El tiempo de ejecución es node.js. Estamos dando una ubicación para nuestro código, que es esta carpeta de funciones Lambda, y luego un punto de entrada, que es main dot handler. Y luego estamos configurando el tamaño de memoria, aumentándolo un poco para que sea más eficiente. Y luego lo que estamos haciendo es tomar esa referencia de API. Así que creamos nuestra API aquí arriba. Y estamos diciendo que queremos agregar una fuente de datos Lambda, y luego estamos pasando esta notes Lambda aquí. Así que creamos la API. Estamos configurando una fuente de datos Lambda. Ahora necesitamos seguir adelante y crear ese código de función Lambda.

Entonces, lo que vamos a hacer es crear una nueva carpeta llamada Lambda-fns, y ahí es donde nuestro código Lambda va a estar en un momento. Pero por ahora, sigamos adelante. Y lo que queremos hacer es agregar nuestros resolvedores. Y necesitamos dos resolvedores porque en nuestro esquema GraphQL, tenemos dos operaciones. Tenemos una consulta y una mutación. La consulta es para ListNotes, así que básicamente estamos diciendo que queremos resolver la consulta ListNotes en esta función. Entonces, cuando se llame esta consulta, simplemente la pasamos a la función Lambda en el evento. Y lo mismo ocurre con la mutación. Cuando se crea un nuevo nodo, cuando se dispara el resolvedor create node, se pasará el evento a la función Lambda.

Y finalmente, lo que necesitamos es algún tipo de database con el que trabajar. Así que vamos a crear una tabla DynamoDB. Y la tabla DynamoDB será donde almacenemos todos nuestros data.

Así que estoy creando una nueva tabla llamada NotesTable utilizando el constructor CDK de DynamoDB. Estamos configurando algunas opciones básicas, estableciéndolo como serverless mediante el uso de pago por solicitud, y establecemos una clave de partición, que básicamente es la clave primaria de ID. Y luego vamos a conceder acceso a la tabla DynamoDB desde nuestra función Lambda, diciendo básicamente, OK, esta función puede interactuar con esta tabla.

Luego llamamos a la función addEnvironment, o establecemos una variable de entorno llamando a NotesLambda.addEnvironment. Y lo que estamos haciendo básicamente es decir, OK, queremos poder acceder a una variable de entorno llamada NotesTable, pero aún no conocemos el valor real de eso. Así que vamos a establecer la variable de entorno allí porque no conocemos el valor del nombre real de la tabla. Pero sabemos que necesitamos acceder a esa tabla. De esta manera, en la función Lambda, podemos hacer referencia a process.env.NotesTable.

Básicamente, creamos la API, creamos una función, mapeamos las operaciones de nuestra API en esa función, y luego creamos una tabla de database y habilitamos el acceso desde nuestra función Lambda a esa tabla. Hicimos todo eso. Y realmente, si lo minimizamos, serían unas 40 líneas de código o algo así.

Ahora que todo eso está creado, ya hemos terminado con nuestro código en nuestro proyecto CDK actual. Ahora lo único que tenemos que hacer es crear nuestras funciones Lambda. Así que voy a tener un archivo notes.ts. Y aquí, vamos a tener nuestro tipo de nota. Esto va a mapear bastante cerca de nuestro tipo GraphQL. Solo lo vamos a usar para nuestros TypeScript aquí. Y lo que queremos hacer ahora es tener un main.js. Ups, esto en realidad debería ser TypeScript, así que voy a cambiarle el nombre a ts. Y en esta función, vamos a tener nuestras dos operaciones que vamos a importar y usar en un momento. Una para crear una nota en DynamoDB, y otra para listar notas. Tenemos un tipo que estamos creando que tiene un par de campos diferentes. Uno es el objeto info que tiene el campo nombre, y el otro es el objeto arguments que tiene la nota. Y básicamente vamos a estar usando estas dos piezas de data, podrías decir, que vienen del evento que llega a la función lambda. Así que cuando se invoque esta función, el evento va a tener un objeto event.info. Y va a tener un objeto event.arguments. Los argumentos son los argumentos pasados a la función o a la operación.

Entonces, createNotes tendría un argumento de notas. GetNoteById podría tener un ID de nota. Y luego el nombre del campo es la propia consulta de GraphQL, o la operación de GraphQL en sí. Por lo tanto, el nombre del campo se referenciará aquí abajo como createNote o listNotes. Vamos a cambiar en función de ese nombre de campo. Así que diremos, vale, si es createNote, queremos ejecutar esta función. Si es listNotes, queremos ejecutar esa función.

Entonces, dicho esto, necesitamos seguir adelante y crear esas dos últimas funciones. Así que tenemos createNote.ts y listNotes.ts. Esta es una función de Lambda para interactuar con DynamoDB. Básicamente, creamos un objeto params, sacamos la nota del argumento, y llamamos al documento, dynamodb.document.put, creando así un nuevo elemento. Aunque esto no es realmente en lo que nos estamos centrando, es un código bastante básico para interactuar con DynamoDB desde una función de Lambda. Y luego, la otra operación es listNotes, que es un escaneo de DynamoDB. Básicamente, vamos a decir que los params que necesitamos son: lo único que necesitamos saber es el nombre de la tabla, que se obtiene de la variable process.environment, y llamamos a document.client.scan, pasando estos params, y esto simplemente va a extraer todo de esa tabla y luego nos lo devolverá.

Si vuelvo a mi CDK, puedes ver que tengo este main.handler referenciado aquí en la carpeta de funciones de Lambda. Si vamos a nuestra carpeta de funciones de Lambda, vamos a main, vemos que la función principal aquí se llama handler, así es como se referencia. Y eso es todo lo que tenemos que hacer, así que vamos a probar esto. Voy a ejecutar npm run build. Esto va a compilar todo ese TypeScript a JavaScript, que es lo que el servicio necesita para ejecutarse. Luego llamaremos a CDK deploy, y luego CDK deploy va a mirar nuestro stack de CDK, y va a decir, oh, necesitamos implementar todo esto. Estamos listos para empezar. Todo lo que tenemos que hacer es decir que sí, y todo este código de infraestructura se implementará. Esto tomará unos minutos.

Vale, después de implementar el stack, ahora podemos probar esto. Así que voy a entrar en la consola de AWS, y vamos a ir a la API que acabamos de crear yendo a AppSync. Y luego vamos a buscar la aplicación Notes. Aquí tenemos la aplicación Notes. Ahora podemos ir a nuestras consultas, y podemos decir, mutación create note. Y luego, simplemente vamos a devolver el ID, nombre. Y creo que también tenemos el valor completado, que vamos a establecer aquí como falso.

Entonces, nuestra API está en funcionamiento. Finalmente, configuraremos una suscripción. Y la suscripción básicamente va a devolver el mismo campo, así que copiemos esos. Y para onCreateNote, queremos esos. Y ahora tenemos una suscripción en ejecución, así que si se crea un nuevo elemento, la suscripción data vendría por aquí.

Entonces, eso es todo. Estoy muy emocionado con este stack porque puedo utilizar mis habilidades de front-end, TypeScript, JavaScript, para construir todo este código de infraestructura. CDK es una comunidad realmente genial. Está creciendo muy rápido. Funciona muy bien con Amplify. Si estás interesado en la computación en la nube de pila completa, échale un vistazo. Sígueme en Twitter en Dabbit3. Gracias por ver. ♪♪♪