Volteando la Nube al Revés

Hoy voy a hablar sobre cómo convertir la cloud del revés, creando una interfaz de programación en la cloud con GraphQL. Esto es mi enfoque como desarrollador front-end al construir aplicaciones en la cloud utilizando GraphQL con AWS y las cosas que he aprendido en los últimos años cuando trabajaba en AWS.

Entonces, ¿quién soy yo? Mi nombre es Nader Dhabit. Actualmente acabo de empezar a trabajar en una nueva empresa llamada Edge and Node. Edge and Node crea y soporta protocolos, aplicaciones y dApps en el ecosistema Web 3 y DeFi. Si estás interesado en saber más sobre lo que estoy haciendo ahora, contáctame en Twitter, dhabit3. También soy desarrollador web y móvil de profesión. Hago mucha enseñanza, escribo mucho y contribuyo bastante al código abierto.

Entonces, ¿cómo se va a dividir esta charla? Primero vamos a hablar de por qué GraphQL, por qué la gente está usando GraphQL y el estado actual del ecosistema de GraphQL. Vamos a hablar de la filosofía detrás de algunas de las cosas que voy a presentar hoy. Luego vamos a ver cómo implementar lo que estoy hablando en la cloud y darle la vuelta a la cloud con una representación de esquema GraphQL. Y luego vamos a ver un poco de código.

Así que empecemos hablando de GraphQL. No voy a hablar de qué es GraphQL en el sentido de la tecnología y cómo funciona. En su lugar, voy a hablar más sobre los beneficios de por qué la gente podría usar GraphQL, así como dónde se encuentra actualmente en el ecosistema. GraphQL es un lenguaje de consulta y manipulación de datos de código abierto para APIs y un tiempo de ejecución para cumplir consultas con datos existentes. A estas alturas probablemente hayas oído mucho sobre GraphQL, así que no quiero aburrirte con muchos detalles aquí. Solo piensa en GraphQL como una especie de reemplazo u otra opción además de Rust. Vamos a hablar de algunos de los beneficios. Estos son beneficios conocidos, pero también un poco de mi perspectiva sobre por qué me gusta GraphQL y por qué he visto a mucha gente adoptándolo, especialmente cuando trabajaba en... Validación de tipos. Obtiene validación y comprobación de tipos de forma nativa. Esto funciona muy bien con muchas de las aplicaciones que estoy construyendo en estos días con cosas como TypeScript y Dart con Flutter. El tiempo real es parte de la especificación real. En lugar de tener que decidir si quieres implementar WebSockets, polling, servidores y eventos, GraphQL normalmente tiene una especificación sobre cómo puedes hacer esto. Los detalles de implementación dependen de ti, pero mucha gente suele utilizar WebSockets para implementar suscripciones. Como desarrollador front-end, realmente no necesito entender los detalles de implementación de nadie bajo el capó. Facilita el cambio entre APIs y entender cómo funciona la parte de tiempo real. Eficiencia de consultas, terminas con un único punto final de GraphQL, pero con ese punto final de GraphQL puedes enviar tantas solicitudes como desees en una sola solicitud. De esto se derivan algunas cosas.

En primer lugar, si quiero tal vez hacer un evento de carga propio cuando mi aplicación se carga, puedo enviar múltiples operaciones en una sola operación GraphQL. Así que puedo decir consultar los datos del usuario, tal vez consultar los datos de los productos para una tienda de comercio electrónico que no voy a renderizar en la página. Incluso puedo obtener datos del carrito de compras que necesito. Todo esto se puede enviar en una sola solicitud en lugar de múltiples solicitudes. Pero también evita el sobreconsumo y el subconsumo en el sentido de que una vez que hayas construido tus consultas y mutaciones de GraphQL, supongo que en este caso serían consultas, puedes pedir exactamente los datos que deseas sin tener que escribir ningún código adicional en el backend. Entonces, para una aplicación que tiene múltiples vistas, tal vez algo que tiene una interfaz web también como una interfaz móvil, en lugar de tener que escribir diferentes puntos finales de API, puedes tener un único punto final de API, obtener los datos más ligeros en la aplicación móvil y luego los datos más pesados en la aplicación web, y todo funciona sin tener que escribir más código.

Una cosa realmente genial de GraphQL es que se documenta automáticamente. Genera automáticamente la documentación de tu API. Esto se hace utilizando la introspección de GraphQL. La introspección es esencialmente la capacidad de consultar qué recursos están disponibles en el esquema de la API actual, y una vez que se te da la API a través de la introspección, puedes ver las consultas, tipos, campos y directivas que admite. Una de las cosas importantes que voy a destacar en esta charla hoy es la consistencia. Para mí, una gran cosa al construir software y aprender a ser un desarrollador eficiente y bueno, para mí y mi career, ha sido encontrar cosas que me permitan aprender una vez y usar en múltiples lugares y ser eficiente. Por ejemplo, una de esas cosas es React. Como desarrollador de React, aprendo React, ahora puedo construir aplicaciones web, pero también puedo construir aplicaciones móviles aplicaciones de escritorio, todo tipo de cosas que la gente hace con React. Alguien, ya sabes, está presentando cómo construir, ya sabes, no solo diapositivas, sino en un software de edición de videos, cosas así. Aprendes React, haces muchas cosas. GraphQL, lo agrupo de una manera similar en el sentido de que una vez que aprendes GraphQL, puedes sumergirte en la API de cualquier persona, no solo dentro de tu propia empresa, sino dentro de cualquier empresa. Entonces, si te vas, te unes a otra empresa, sabes cómo usar GraphQL, puedes ser inmediatamente productivo. Miras el gráfico, sabes lo que está pasando. Pero lo que es aún más interesante son algunas de las cosas que voy a ver y mostrar en un momento en el que las personas están implementando estas implementaciones más grandes y más interesantes de gráficos y diferentes ecosistemas, y yo como desarrollador de GraphQL, en realidad puedo ir y ser muy, muy eficiente en esas diferentes capas sin tener que aprender nada. Y esto es algo que tuiteé hace poco tiempo, GraphQL, aprende una vez, crea, lee, actualiza, elimina y suscríbete en cualquier lugar. Es una especie de juego con React, aprende una vez, escribe en cualquier lugar o algo así. Lo siento, eso fue React Native. En general, es la misma idea.

Y luego lo segundo que voy a enfatizar es la consistencia, pero también la implementación de GraphQL en una arquitectura de microservicios. GraphQL es perfecto para sistemas complejos y microservicios como he explicado aquí. Pero esencialmente, al integrar múltiples sistemas detrás de su API, GraphQL los unifica y oculta su complejidad detrás de este gráfico. El servidor de GraphQL es el encargado de obtener los datos de los sistemas existentes y empaquetarlos en el formato de respuesta de GraphQL.

Ahora echemos un vistazo a GraphQL. En este punto, GraphQL es definitivamente popular. AWS, Netflix, Twitter, Peloton, Reddit, Twilio, GitLab, Twitch, PayPal, Spotify. Quiero decir, nombralo, la mayoría de las empresas grandes en estos días lo están utilizando para cosas críticas o al menos en algún lugar. Estamos viendo una adopción más amplia. Ya es algo común.

Algo que realmente me interesa es el sentimiento de los desarrolladores. Supongo que el sentimiento de los desarrolladores es importante para mí, ya que me ayuda a comprender qué seguirá siendo relevante y qué eventualmente desaparecerá. Al final del día, si a los desarrolladores les gusta hacer o usar algo en particular, es más probable que no solo se mantenga, sino que también mejore. A medida que las herramientas mejoran, más personas se unen al ecosistema y se reciben más comentarios para mejorar lo que se está construyendo. El sentimiento de los desarrolladores hacia GraphQL es muy alto en general, según las diferentes encuestas que he visto. Estas encuestas no cuentan toda la historia, pero me indican que a los desarrolladores les gusta usar GraphQL, y eso me dice mucho. Me importa lo que los desarrolladores valoran porque me interesa comprender hacia dónde se dirige la industria, para poder seguir la misma dirección. Es una preferencia personal, ya que todos somos diferentes, ¿verdad? Haz lo que funcione para ti. Pero para mí, lo que ha funcionado es dirigirme hacia una dirección en la que sé que si invierto tiempo en aprender y hacer algo, podré aprovecharlo en el futuro, ya sea consiguiendo un trabajo que utilice esas habilidades o haciendo consultorías o lo que sea. Tal vez escriba un libro.

Dicho esto, lo que realmente trata esta charla es la idea de usar GraphQL como una puerta de enlace de API. Hablaré sobre esto de varias formas antes de llegar a Cloud. Hablaré un poco más sobre microservicios. Hablaré sobre un caso de uso interesante relacionado con APIs de terceros, y también quiero hablar sobre Blockchain y Ethereum. Esto tiene algo que ver con el trabajo que tengo actualmente. Hablemos sobre microservicios. Puedes pensar en las arquitecturas de microservicios de varias formas. Una implementación muy básica podría ser tomar varios puntos finales que tienes y hacerlos accesibles dentro de tu aplicación, y estás llamando a este único punto final en AWS. Tal vez este punto final esté configurado en DigitalOcean o en otros servicios, pero todos son diferentes microservicios y tienen diferentes puntos finales y diferentes APIs. Esto no suele ser la forma correcta de hacerlo, porque terminas con una experiencia del desarrollador del lado del cliente muy inconsistente y no entiendes cómo se hace nada porque todo se hace de manera un poco diferente.

Lo que suele verse es que alguien coloca una puerta de enlace de API frente a todos estos microservicios. Se obtiene un punto final de API consistente y luego se utilizan diferentes cargas útiles, diferentes parámetros de URL, cosas así. Algunas de estas cosas se abstraen detrás de esta puerta de enlace de API y se logra una mayor consistencia. Lo que se está volviendo realmente popular en AWS y entre muchos clientes que veo que lo utilizan, pero también fuera de AWS, es simplemente implementar GraphQL como tu puerta de enlace de API. Al hacer esto, obtienes todos los beneficios típicos que obtendrías de una puerta de enlace de API REST tradicional, pero con todos los diferentes beneficios que ofrece GraphQL. Definitivamente, la verificación de tipos en tiempo real que se obtiene de cualquier mutación, lo cual es realmente impresionante, la eficiencia de las consultas, la documentación de la API, todas las cosas de las que ya hemos hablado.

Ahora, eso está bien y todo, la gente lo está haciendo. Hablemos de casos de uso más interesantes. Uno de ellos es lo que Sean Grove está haciendo en One Graph con APIs de terceros. One Graph es realmente genial porque reúne varios servicios detrás de un único punto final de GraphQL, un montón de APIs diferentes que tradicionalmente eran APIs REST. Algunas de ellas también podrían ser APIs de GraphQL, pero la idea es que tienes este único gráfico con el que puedes trabajar. Lo que eso significa para mí como desarrollador, si alguna vez has trabajado con algo como la API de Twitter o la API de YouTube o Netlify, Salesforce, Air Table, cualquiera de estas APIs, todas se implementan de manera un poco diferente, ¿verdad? Pero ¿qué pasaría si hubiera una forma única de hacer esto? ¿Qué pasaría si cada empresa estuviera implementando su capa de API de la misma manera? Bueno, eso es más o menos lo que hace One Graph, y eso es lo que ahora puedes hacer con One Graph. Así que puedes consultar APIs como Air Table, Salesforce, CloudFlare, Dev.to, Dribbble, Dropbox, MailChimp, Google, YouTube, Twitter, Trello, Stripe, todo tipo de servicios. Creo que hay docenas de servicios a los que puedes consultar desde este único gráfico. Es realmente interesante. Realmente te recomiendo que lo pruebes porque, como desarrollador, ahora puedo sumergirme en este gráfico y tener éxito de inmediato sin tener que leer ninguna documentación, y cualquier documentación que necesite está ahí mismo con esa introspección de esquema de GraphQL que mencioné antes. Es autoexplicativo. Es muy bueno. Echa un vistazo a One Graph. Me gusta mucho la idea de hacer esto, y creo que puede haber incluso un par de personas más haciendo cosas similares con estas APIs de terceros.

Lo siguiente de lo que quiero hablar es blockchain y Ethereum. Dentro de este espacio, dentro del espacio de finanzas descentralizadas y la Web 3, tienes esta idea de aplicaciones descentralizadas o lo que se conocen como DApps. Con todo este ecosistema, hay todo tipo de aplicaciones diferentes que están surgiendo, construidas de esta manera utilizando estas tecnologías, supongo que podrías decir. Cosas relacionadas con préstamos, intercambio de tokens, es decir, cambiar moneda entre sí, inversiones, financiamiento colectivo, pagos, todo tipo de cosas. Es un espacio realmente interesante, algo que me ha interesado mucho. Echemos un vistazo a uno de estos, Compound. Compound es un protocolo de mercado monetario construido con Ethereum. Permite a cualquier persona o incluso a cualquier máquina ganar fácilmente intereses al prestar sus activos de criptomonedas. Los activos prestados luego se pueden utilizar como garantía para pedir prestados otros activos bloqueados en el protocolo. Por el momento, no se pueden construir aplicaciones excelentes directamente sobre blockchains.

El problema es que necesitas tener los data indexados y organizados para una recuperación eficiente. Así que piensa en la web y en lo que podrías necesitar hacer si no existiera algo como un motor de búsqueda. ¿Cómo encontrarías todos estos data? Probablemente tendrías que hacer mucho trabajo. De manera similar con los datos de blockchain, si quieres obtener data de la blockchain, lleva mucho tiempo, mucho trabajo y mucho esfuerzo. Y la mayoría de las personas, la mayoría de las empresas terminan indexándolo en su propio servidor, lo cual rompe la idea de descentralización.

Entonces, con blockchain, esta capa de indexación, ese es tradicionalmente el trabajo que hacen las bases de datos en esta pila tecnológica descentralizada. Pero esa capa de indexación faltaba en la pila de Web3. Y ahí es donde entra en juego el gráfico. El gráfico es un protocolo de indexación para consultar redes, como Ethereum, IPFS y en el futuro otras blockchains. Entonces, con el gráfico, cualquiera puede construir y publicar estas API abiertas llamadas subgrafos, haciendo que los datos sean fácilmente accesibles en forma de una API de GraphQL. Antes, los equipos del gráfico tenían que desarrollar y operar servidores de indexación propietarios ellos mismos, lo cual no solo requiere recursos de ingeniería y hardware significativos, sino que también rompe esta importante propiedad de seguridad, o todas las propiedades de seguridad necesarias para la descentralización.

Y el gráfico resuelve ese problema al ofrecer este protocolo de indexación consistente. Y lo hace utilizando GraphQL. Ahora cualquiera puede construir y publicar estas API abiertas llamadas subgrafos utilizando estos datos más fácilmente accesibles. Muchas empresas están utilizando el gráfico ahora. Muchas empresas diferentes que son muy, muy populares tienen una gran escala, supongo que podrías decir en este punto. Así que Compound, Uniswap, muchas de esas plataformas NFT están utilizando eso, incluyendo Foundation, que es una plataforma NFT bastante genial para comprar NFT y arte y cosas así. Así que esta es otra aplicación de GraphQL. Si aprendes GraphQL, no solo puedes acceder a todas estas otras API que estaba mirando con OneGraph, además de todo lo que podrías estar haciendo en tu trabajo diario, ahora puedes también consultar datos de blockchain, lo cual me parece muy interesante. Además de eso, ¿qué hay de la nube? Esto es realmente de lo que estoy aquí para hablar. Como desarrollador front-end, comencé en AWS y miré la consola de administración de AWS y me intimidé mucho. Incluso como alguien que ha estado trabajando en AWS durante más de tres años, todavía me intimida este panel de control. Lo que realmente me gustaría hacer, quiero crear un esquema como lo haría con mis API típicas de GraphQL. Quiero poder definir los data con los que me gustaría trabajar. Entonces, en este caso, tomemos un ejemplo básico nuevamente, vamos a ver un tipo de producto y un tipo de etiqueta. Y quiero tener un par de operaciones que interactúen con alguna capa de data que traiga esta información. Entonces, tal vez quiera acceder a un tipo de base de datos para la consulta de productos.

Quiero acceder a un tipo diferente de base de datos para la consulta de productos. Y quiero acceder a un servicio de aprendizaje automático incluso para mi consulta de detección de etiquetas en imágenes. Entonces, ¿cómo puedo hacer que algo como esto funcione dentro de AWS, verdad? Esa es más o menos la pregunta que quiero responder. Me gusta usar GraphQL, pero no sé cómo juntar todas estas cosas. Incluso tal vez quiera hacer algo más complicado donde tengo esta consulta de obtener información de cuenta donde combinamos múltiples tipos diferentes de fuentes de datos, bases de datos, y todo se devuelve en una sola consulta. Al igual que lo que normalmente harías con GraphQL, ¿cómo lo vamos a hacer en AWS, aprovechando muchos de estos diferentes servicios y cosas de AWS?

Estamos hablando de construir APIs en la nube en este punto. ¿Cómo construyes APIs en la nube? Hay dos formas principales de hacerlo con algo como AWS. Está el servicio de API Gateway, que es un servicio de API REST, y luego está AWS AppSync, que es un servicio de GraphQL administrado. Voy a hablar un poco sobre ambos. Y dentro de ambos, hay tres piezas principales, en mi opinión, que necesitas comprender cómo funcionan. Uno es el entorno de ejecución. El entorno de ejecución es donde realmente se ejecuta tu código. Esto puede ser un servidor o puede ser una función sin servidor. Y luego tienes tus permisos. ¿Cómo hago que mi código de función se comunique con esta base de datos? ¿Y cómo hago que funcione? ¿Cómo lo configuro? Y finalmente, ¿cuáles son los diferentes SDK que necesito para interactuar con estas fuentes de datos? Entonces, estoy en esta función, estoy escribiendo TypeScript. Quiero interactuar con esta base de datos. ¿Cómo lo hago en realidad? Esas son las tres cosas que quiero desglosar aquí.

En cuanto al entorno de ejecución, hay dos tipos principales de entornos de ejecución. Tienes el entorno con servidor, lo que significa que se ejecuta en un servidor que tú mantienes. Y luego tienes el sin servidor, lo que significa que estás trabajando en una función sin servidor. Y en el entorno con servidor, tienes beneficios. Hay compensaciones en todo, ¿verdad? Cuando administras tu propio servidor, tienes control total sobre todo, lo que significa que tienes todo el entorno de ejecución. No hay limitaciones aparte del sistema en el que se ejecuta tu servidor, podrías pensar, ¿verdad? Lo cual es bueno y malo, porque también tienes más cosas que debes tener en cuenta. Y las desventajas son que tienes que hacer todo esto y escribirlo tú mismo. Entonces, tienes que implementar las suscripciones tú mismo. Tienes que comprender cómo escalar estas suscripciones. Tienes que comprender cómo escalar tu API en general. Es posible que tengas que implementar el almacenamiento en caché. También tienes que lidiar con los servidores mismos, y con todas las cosas relacionadas con la seguridad, autenticación, autorización.

Y tienes que pensar en todas las cosas específicas de GraphQL, como las consultas maliciosas. Así que todas estas cosas, son cosas que tienes que implementar tú mismo. Así que nuevamente, hay compensaciones.

Luego vamos a hablar de, hemos hablado de server full. Hablemos de serverless. Así que hay dos formas principales de hacer esto en AWS al menos. Una es usando AppSync, que es un servicio GraphQL administrado. Y luego está usando Amazon API Gateway en AWS Lambda, que no está realmente diseñado para GraphQL. Así que me voy a centrar en AppSync. Y este es un servicio del que soy un gran fan. Si has visto mi canal de YouTube, ya no trabajo en AWS, pero sigue siendo mi servicio en la nube favorito para trabajar y lo será. AppSync es un servicio de API GraphQL administrado. Definitivamente recomiendo echarle un vistazo. Pero todo de lo que voy a hablar va a ser utilizando AppSync.

Entonces, ¿cuáles son algunos de los beneficios de usar serverless? Los beneficios de serverful, hemos hablado de que tienes el control del entorno de ejecución, pero tienes que hacer mucho más trabajo. Creo que serverless cambia eso en cierto sentido, haces menos trabajo, pero también tienes menos control sobre las cosas que actualmente no son compatibles. Por ejemplo, al trabajar con AppSync, tienes seguridad integrada, autenticación y autorización. Tienes suscripciones integradas que pueden escalar hasta decenas de millones de clientes conectados, escalabilidad, resistencia, todo esto se tiene en cuenta. El almacenamiento en caché está integrado. No tienes que administrar tus servidores. Tienes menos código con el que lidiar y estás utilizando un modelo de pago sin servidor. En lugar de pagar por un gasto de capital, un gasto constante, lo estás intercambiando por un gasto variable, lo que significa que estás pagando por el cómputo que se está utilizando. Si está inactivo, no se te cobra.

Entonces, ¿cuáles son las desventajas de usar algo como AppSync? Estás limitado por el servicio de API que se te proporciona. Si AppSync no ofrece algo que necesitas, estás un poco fuera de suerte. Si conoces tu consistencia de alta escala, de manera constante a lo largo del tiempo, podría ser más barato administrar tus propios servidores. Creo que serverless es especialmente adecuado para entornos dinámicos donde tu tráfico sube y baja, y no estás seguro de cómo será tu tráfico en cuanto a un modelo de costos. Además, si necesitas tareas de larga duración, serverless no es un buen entorno para eso. Normalmente necesitas tu propio servidor para algo así. Mi recomendación, basada en todo lo que he hecho, todo con lo que he trabajado, soy un gran fan del entorno de ejecución sin servidor, especialmente de AppSync.

Así que tómalo con precaución. Yo probaría lo que quieras tú mismo antes de tomar cualquier decisión.

Lo siguiente son los permisos. Ahora que entendemos que queremos usar esta o aquella implementación de servidor o serverless, ¿cómo vamos a lidiar con cosas como los permisos? En AWS, en Cloud, tienes esta idea típica de IAM, que significa Identity and Access Management. Identity Access Management suena más complicado, creo, de lo que es. Así que veamos qué significa realmente.

Digamos que he creado un entorno, he creado esta función lambda donde puedo escribir algo de Typescript. Tengo esta tabla DynamoDB y quiero hacer una llamada a la API, o quiero hacer una consulta a la base de datos, supongo que podrías decir, desde mi función a esta tabla base de datos. Ahora, de forma predeterminada, tienes acceso restringido. Por defecto, se te da el acceso denegado en la mayoría de los entornos de Cloud. Lo que significa que si intento acceder a algo y no le he dado estos permisos, entonces, por defecto, va a decir que no puedes hacer eso.

Todo lo que IAM está diciendo, es que voy a darle a este recurso permiso para realizar estas diferentes operaciones en este servicio. Podría decir que quiero que mi función lambda pueda crear, actualizar, eliminar y leer de esta tabla. Una vez que se establece ese permiso utilizando IAM, ahora puedo empezar a interactuar con esta base de datos. Vamos a ver cómo se ve esto en el código en solo un segundo.

Luego, lo último que debes tener en cuenta, si estás trabajando con uno de estos entornos de ejecución, son los SDKs. Lo bueno de esta idea de los SDKs es que solo hay un SDK principal con el que tienes que lidiar en el servidor. Ahora, si estás trabajando con AppSync, puedes hablar directamente con alguna base de datos como DynamoDB, Elasticsearch o Serverless Aurora, o puedes mapear tus operaciones en este entorno de ejecución como Lambda y hablar con cualquiera de los servicios que desees. Puedes ejecutar Node.js, puedes ejecutar Python, puedes ejecutar Go. Todos estos diferentes entornos de ejecución tienen un SDK de AWS que admite todos los demás servicios. Todo lo que necesitarías hacer sería importar el SDK de AWS y Node.js, y puedes hacer algo como esto.

Si quieres hablar con DynamoDB, adelante e importa el cliente de DynamoDB y crea nuestro comando diciendo que queremos hacer algo como escanear, en este caso, el comando de escaneo. Luego, en cuatro líneas de código, incluidas las importaciones, sin incluir el controlador, podemos escanear esta tabla y obtener todos los datos que queremos de la tabla. Hay cientos de servicios con los que puedes trabajar desde este SDK de AWS, un proyecto bastante masivo. Digamos que quieres trabajar con el servicio de aprendizaje automático como reconocimiento. Todo lo que necesitas hacer es importar el SDK de AWS. Vamos a importar el cliente de reconocimiento y el comando de detección de etiquetas. Construimos nuestro comando, pasando los parámetros. En este caso, queremos especificar el bucket de S3 y la imagen de la que queremos detectar etiquetas. Luego ejecutamos la operación y tenemos esos datos de retorno, que están en formato JSON en este ejemplo.

Dicho esto, todavía estoy confundido porque ¿cómo realmente juntamos todas estas cosas? Tal vez entendamos que necesitas todas estas cosas, pero juntarlas sigue siendo muy, muy difícil en mi cabeza en este momento. Hablemos de hacer esto un poco más fácil uniendo todas estas cosas y desplegando algo. Aquí es donde entran en juego muchas de lastooling y cosas en las que hemos estado trabajando cuando estaba en AWS para facilitar esto. Hay un par de opciones de implementación. Por supuesto, puedes ir directamente al panel de AWS y hacer todo esto, pero eso para mí es más complicado que usar algunas de estas herramientas que existen. En particular, con AppSync, AWS CDK, AWS SAM, AWS Amplify, y el framework serverless son, en mi opinión, algunas de las más fáciles de usar. También puedes usar CloudFormation, que es muy robusto, pero también es una forma muy detallada de hacer esto. Recomendaría usar Amplify, el framework serverless, o tal vez CDK si estás comenzando. Voy a hablar sobre Amplify y CDK para darte una visión general de dos formas diferentes de hacer esto.

Con Amplify, si quieres agregar una API deGraphQL, simplemente ejecutas Amplify add API. En realidad, no tienes que configurar todos estos diferentes servicios. No tienes que lidiar con los permisos. La CLI de Amplify escribirá todo el código de infraestructura por ti y lo conectará todo. A partir de ahí, todo lo que necesitas hacer es lidiar con tu esquema deGraphQL, y en tu esquema, puedes usar estas directivas que forman parte de lo que se llama la biblioteca de transformación deGraphQL para modelar y lidiar con muchas de estas otras cosas por ti también. Entonces, digamos que queremos tener una base de datos de publicaciones en una tabla de DynamoDB. Todo lo que necesitamos agregar es esta directivaat model, y ahora tendremos nuestra tabla que se crea, así como todos los resolvers que necesitaremos para las operaciones CRUD, las operaciones de lista y las suscripciones. A partir de ahí, podemos modificar nuestro código del resolver si queremos. También podemos modelar reglas de autorización. Entonces, en este caso, tengo esta directivaat auth rules que dará permisos de propietario al elemento que se crea. Y hay todo tipo de reglas diferentes que puedes establecer aquí. De hecho, creo que hay siete directivas de nivelrate que también puedes usar para hacer otras cosas como modelar relaciones entre datos. También podemos decir, oh, quiero asignar una consulta o mutación deGraphQL a una función deLambda. Y luego, dentro de esta función, tenemos todo el entorno de ejecución completo. Ahora, todo lo que tienes que hacer es agregar esta directivaat function y la biblioteca de transformación deGraphQL conectará todo por ti utilizando la CLI de Amplify. Así que siempre que tengamos esta función creada, ahora podemos ir a esta función, escribir toda la lógica empresarial que necesitamos y devolver una matriz de imágenes. Siempre y cuando vuelva en la estructura definida en nuestro esquema, entonces estamos listos. Es muy poderoso usar la directivaat function. Soy un gran fan de eso.

Veamos un poco de código real y en el código vamos a ver un CDK. Entonces, con CDK, es posible que desees crear un nuevo proyecto para hacer esto, simplemente ejecutas CDK init, esto configurará todo lo que necesitas y creará un stack para que puedas comenzar a escribir código.

Ahora veamos cómo podríamos crear una API de GraphQL respaldada por una función Lambda y una tabla DynamoDB. Diremos, hey, queremos crear una nueva API. Entonces importamos la biblioteca de AppSync y llamamos a AppSync.GraphQLAPI. Ahora podemos configurar varios parámetros como el nombre, la ubicación del esquema y cualquier cosa adicional como nuestro tipo de autorización base. En este caso, queremos una API pública con una clave de API. Esto desplegará nuestra API. Podemos ejecutar este código por sí solo y ahora tenemos nuestra API.

Sin embargo, la API no hará nada porque no tenemos una, no hemos definido dónde deben mapearse nuestros resolvers y no hemos definido una fuente de datos. Así que a continuación podríamos definir nuestra fuente de datos. Podríamos decir que queremos tener una función Lambda como fuente de datos, lo que significa que vamos a mapear nuestras operaciones de GraphQL en la Lambda. Pero para hacer eso, primero debemos crear nuestra función Lambda. Así que lo estamos haciendo aquí. Estamos configurando el runtime a node.js. Estamos definiendo el tamaño de memoria y estamos definiendo la ubicación del código para el código que vamos a ejecutar. Y finalmente, ahora tenemos nuestro esquema. Tenemos nuestra API y tenemos nuestra función Lambda y tenemos nuestra fuente de datos.

Ahora podemos comenzar a mapear operaciones que hemos definido en nuestro esquema en esta fuente de datos. Todo lo que tenemos que hacer es decir create resolver. Establecemos el nombre del tipo y el nombre del campo. Así que en este caso estamos diciendo, queremos una consulta de listar publicaciones, una mutación de crear publicaciones, y una consulta de buscar imágenes. Y ahora estamos mapeando estas operaciones de la API en Lambda. Dicho esto, diría que si quieres aprender más sobre cómo hacer esto, visita mi canal de YouTube. Tengo muchos videos sobre cómo construir este tipo de arquitectura. youtube.com/natterdabit. También te recomendaría que veas mi GitHub, github.com/dabit3. Consulta el blog móvil de AWS, la documentación de Amplify. Realmente creo que este es el futuro de la implementación de API en la nube. Veremos mucha más adopción. Soy un gran fan de esto. Si no te has dado cuenta, realmente me importa este tema.

Estoy realmente emocionado por esto. Sí, gracias por revisar mi charla. Una vez más, soy natterdabit. Trabajo en DevRel en Edge and Node. Echa un vistazo a Edge and Node. Es mi nueva empresa. Estoy muy emocionado por eso también. Y muchas gracias por revisar mi charla. Nos vemos por aquí.

Estoy realmente, realmente feliz de estar aquí y este es un gran evento. Quiero decir, esto es simplemente increíble, como si simplemente... Es difícil expresarlo con palabras cuántas cosas increíbles han sucedido durante todo esto, entre las panel discussions, todas las charlas geniales, las masterclasses. Realmente buen trabajo de todos los organizadores. Eso es todo lo que tengo que decir porque sé que esto debe ser mucho trabajo. Sí, muchas gracias. Sí, es una conferencia muy agradable, eso seguro. Es la primera vez que la veo. Espero hacerlo en el futuro, nunca se sabe, pero es muy agradable ver, como todos están haciendo mucho trabajo y, por supuesto, invitando a oradores realmente geniales como tú.

Entonces, hiciste la pregunta en primer lugar, ¿y cómo te presentas en las fiestas? Puedo responder eso, me presento como Catalyn o Unicorn Dev, pero dejaste un par de puntos allí, como desarrollador web, parece que está ganando con un 51%. ¿Qué opinas al respecto? Sí, eso es bastante genial. Como, esta fue una pregunta que se hizo en la encuesta State of JS que pensé que tenía algunas respuestas interesantes, pero creo que está muy enfocado en el front-end, al igual que este evento. Pero me preguntaba cómo se distribuye entre los desarrolladores de front-end y los desarrolladores full-stack que vienen a este tipo de eventos, pero también quién quiere ingresar al front-end que podría venir aquí, y luego alguien que es más como un programador, pero más en el nivel C. Entonces, eso típicamente sería como un CTO. Así que pensé que era una buena variedad de preguntas. Pero realmente me sorprendió ver cuántos desarrolladores full-stack hay aquí, pero creo que esa tendencia está aumentando con todo este serverless full-stack y cloud full-stack y Vercel y todas estas otras cosas que están surgiendo que permiten a los desarrolladores involucrarse en el full-stack. Gran parte de las cosas en las que realmente me he enfocado en mi career, también en los últimos años se orienta hacia eso también. Así que eso es bueno, resultados interesantes. Bien.

Así que tenemos algunas preguntas del público. Comenzaré con la pregunta dirigida por John B, ¿tienes alguna fuente recomendada para obtener más información sobre estos temas? Tal vez GraphQL o la charla que diste? Sí, quiero decir, lo que fácilmente puedo mostrarte y enseñarte es que escribí una publicación en el blog que se llama exactamente igual que esta charla.

Se llama Turning the Cloud Inside Out. Así que permíteme pegar el enlace allí en el discord. Pero, quiero decir, realmente esto es una culminación de todo lo que ha sucedido en el ecosistema en los últimos años. Así que cualquier cosa que se haya escrito sobre GraphQL desde un nivel teórico probablemente sería bueno leerlo también.

Si quieres seguir a algunas personas interesantes, hay un montón de personas, pero tal vez las personas que están en este espacio son Sean Grove de OneGraph, lo mencioné en la charla. Siempre está haciendo cosas realmente innovadoras. Yuri Goldstein también está haciendo cosas realmente interesantes que están relacionadas con el tooling de GraphQL. Eve Pursello es como, con mucho, la mejor profesora en el espacio, tal vez porque ha escrito libros, tiene un curso muy completo que se lanzará, muchas cosas interesantes. Así que si sigues a esas tres personas y ves parte del trabajo que han hecho, aprenderás mucho sobre GraphQL.

Genial, no estoy seguro si se nos está acabando el tiempo. ¿Tenemos alguno? Bien, así que se nos está acabando el tiempo. Nadir, fue un placer, realmente te extraño. Espero que esta pandemia termine y podamos volver a encontrarnos, tomando algo y simplemente discutiendo en general. Muchas gracias por tu charla. Fue un placer tenerte aquí. Gracias. Sí, es un honor estar aquí, gracias.