Construyendo una Puerta de Enlace de API en la Nube Altamente Escalable

♪ ¡Hola a todos! Bienvenidos a mi charla. Voy a hablar sobre cómo construir una puerta de enlace de API en la nube altamente escalable con cloud GraphQL. Mi nombre es Nader Dabat. Soy un defensor principal del desarrollo en el equipo web y móvil de AWS, donde me enfoco en reducir las barreras de entrada a la computación en la nube. Mi equipo trabaja en muchas tecnologías diferentes. Trabajamos en la web. Trabajamos en móviles. Trabajamos en el backend, infraestructura como código, todo tipo de cosas.

Pero realmente mi equipo se centra en la intersección entre la web, la movilidad y la computación en la nube. Así que algo así como la intersección entre el frontend y la cloud, la nube de pila completa, se podría decir. Y en particular, una de las cosas que me interesa mucho es esta idea de una nube de pila completa y sin servidor de pila completa. Así que creo que la charla que voy a dar hoy se ajusta muy bien a esa idea, porque puedo usar mi conjunto de habilidades existente en el frontend como desarrollador frontend para construir estas aplicaciones escalables en la nube utilizando GraphQL.

Tengo un par de libros, pero el más reciente y el que más se relaciona con esta charla es `Full-Stack Serverless` de O'Reilly. Así que si estás interesado en construir estas aplicaciones en la nube con React y GraphQL o simplemente con GraphQL y cualquier framework frontend, definitivamente échale un vistazo. Todo está construido con GraphQL y AWS.

Esta charla se dividirá en tres partes principales. Es una charla de 20 minutos, no mucho tiempo. Así que voy a repasar brevemente algunos conceptos y luego voy a hacer una demostración de codificación en vivo que construirá las cosas de las que estoy hablando, porque para mí, me gusta ver código. Aprendo mucho cuando veo código. Y la idea que voy a construir es utilizar infraestructura como código en TypeScript. Así que en mi opinión, es un tema realmente divertido. Así que voy a repasar cuáles son los desafíos de construir un servidor GraphQL personalizado. Voy a hablar sobre AWS AppSync y luego voy a hacer esa demostración de codificación en vivo.

Entonces, ¿cuáles son algunos de los desafíos para construir una API de GraphQL desde cero? En mi opinión, se divide en cuatro partes principales. La primera y, en mi opinión, la más importante es la security. Cuando construyes tu API de GraphQL, no solo tienes que hacer que funcione, sino que también tienes que tener en cuenta muchas cosas diferentes y muchos escenarios diferentes en torno a la authentication, la autorización y el control de acceso. La mayoría de las veces, tu API necesitará varios tipos de escenarios de autorización. Así que si piensas en algo como Twitter, piensas en algo como Instagram, Facebook, todas las aplicaciones más populares y modernas con las que probablemente interactúes hoy en día, suelen tener una combinación de acceso público y privado.

Entonces, ¿cómo implementas realmente este acceso público y privado? Y si estás haciendo esto desde cero, suele ser mucho trabajo. Tienes que pensar en cosas como la encriptación, tienes que pensar en cómo se almacena la información del usuario, y todas estas cosas.

Y luego están los escenarios específicos de GraphQL, como consultas maliciosas, profundidad de consulta y cosas así. Y luego las reglas de seguridad típicas y los problemas con los que te enfrentas dentro de la superficie de la API, como ataques DDoS y cosas así.

El siguiente área principal es la escalabilidad. Entonces has construido esta API. Funciona. Pero ¿qué sucede cuando obtienes un aumento de 10,000 usuarios al mismo tiempo, o algo se vuelve viral y obtienes 10 veces, 100 veces o incluso 1,000 veces más visitantes? Quieres que tu API sea escalable. Entonces, ¿cómo provisionas realmente tu infraestructura y lo haces de manera rentable para que tu aplicación se escale? Y luego tienes que pensar en cosas específicas de GraphQL, como las suscripciones. Una de las cosas en las que hemos trabajado mucho y en lo que nos hemos enfocado en los últimos años es hacer que las suscripciones sean escalables. Tenemos clientes que han escalado nuestras APIs a decenas de millones de dispositivos conectados para un solo punto final de API. Este fue un desafío muy difícil y típicamente es algo difícil de hacer en general.

Y luego, algo que debes tener en cuenta es la velocidad de desarrollo. Entonces, cuando estás construyendo tu API, ¿qué sucede cuando necesitas agregar una nueva función? ¿Cuando necesitas versionar algo? ¿Cuando necesitas modificar una fuente de datos existente o incluso agregar una nueva fuente de datos? ¿Qué sucede cuando tu API comienza a volverse compleja? ¿Esto va a frenar a tu equipo y, por lo tanto, ralentizar el desarrollo de toda tu aplicación? Y finalmente, está el costo. Y cuando hablo de costo, no solo me refiero al costo monetario, sino también al costo de oportunidad y las horas de desarrollo, y las cosas que consideras, por ejemplo, si eres una startup o simplemente una empresa en general, y tienes competidores que están haciendo lo mismo que tú, si necesitas construir algo y probarlo y no sabes si funcionará o no, digamos que pasas tres meses, seis meses construyendo esto. Eso es un costo de oportunidad que debes considerar realmente, porque si esto no funciona, has gastado mucho dinero, has gastado mucho tiempo, y ese tiempo podría haberse invertido en construir algo más, si hubieras sabido que esto no iba a funcionar. Entonces, ¿cómo tienes en cuenta todas estas cosas y cómo lo haces de manera efectiva en todas estas áreas diferentes?

Esto es donde creo que AWS AppSync, el servicio en el que hemos estado trabajando en los últimos años, realmente destaca en todas estas áreas diferentes. Y AppSync es un servicio administrado de GraphQL de AWS. Me gustan mucho los servicios administrados porque cuando estás lidiando con un servicio administrado, este equipo está trabajando en este único problema durante años. Todas esas personas están especializadas en resolver este único problema. Entonces, cuando te unes a un servicio administrado, típicamente estás obteniendo años de trabajo, mucho dinero gastado y muchos casos especiales resueltos para lidiar con este único problema. Entonces, si puedes encontrar algo que se ajuste al desafío que estás tratando de resolver y sea un servicio administrado de un equipo en el que puedas confiar, a menudo es un enfoque bueno para hacer algo sin tener que construirlo desde cero y reinventar la rueda.

De todos modos, AppSync te permite construir estas APIs, cualquier cosa que necesites mapeada a través de GraphQL se puede hacer con AppSync. Comienzas con la nueva API de AppSync, defines tu esquema. Aquí en tu esquema defines tus tipos, por supuesto, tus consultas, tus mutaciones y tus suscripciones. A partir de ahí, configuras los diferentes tipos de autenticación y autorización. Entonces, puedes tener un tipo base y el tipo base podría ser público, podría ser privado, podría usar un proveedor OIDC, podría ser lo que sea. Pero también puedes tener tipos de autorización adicionales. La mayoría de las APIs, como mencioné, tienen múltiples escenarios de autorización. Entonces, la mayoría de las aplicaciones que se lanzan a producción tienen múltiples tipos de autenticación. Típicamente tienes algún tipo de acceso público junto con algún tipo de acceso privado. Después de configurar tus tipos de autenticación, configuras tus fuentes de datos.

Lo interesante de AppSync es que estás mapeando tus solicitudes de API directamente en estas bases de datos realmente altamente escalables y fuentes de datos. Entonces, puedes mapear tus solicitudes de API de GraphQL directamente a algo como DynamoDB, acceso de primera clase a DynamoDB, Aurora sin servidor para SQL, Amazon Elasticsearch. Incluso puedes mapear tus solicitudes de API de GraphQL a algo como MongoDB que está fuera de AWS. Debido a que los resolvers de GraphQL son solo funciones, tienes completa flexibilidad sobre toda la lógica empresarial que necesites. No solo tienes este servicio administrado que maneja la escala, sino que también tienes toda la flexibilidad que normalmente obtendrías al construirlo desde cero.

A partir de ahí, escribirías la lógica de tus resolvers. Puedes elegir entre resolvers predefinidos que tenemos para diferentes escenarios populares. O puedes escribirlo completamente desde cero. Y puedes hacerlo en casi cualquier lenguaje que desees utilizar y que sea compatible con AWS Lambda. Puedes escribirlo en Python, TypeScript, .NET, Go, lo que prefieras, JavaScript también, por supuesto. Y luego, a partir de ahí, implementas tu API y haces iteraciones. Hay un par de formas diferentes de implementar tu API. Y voy a hablar de las dos principales con las que he trabajado y la que voy a mostrar, que es CDK. Entonces, AWS Amplify y AWS CDK son las dos con las que he trabajado mucho. Pero realmente puedes implementar AppSync con cualquier cosa que admita CloudFormation, que es un código de infraestructura para AWS. Entonces, si te gusta usar el framework serverless, SAM, cualquier cosa así, también funciona.

Si estás trabajando con AWS Amplify, obtienes algunas cosas que no obtienes de otros proveedores de CloudFormation. Obtienes generación de código GraphQL, por lo que inspeccionaremos tu esquema de GraphQL y generaremos todas las diferentes operaciones de GraphQL para la plataforma en la que te encuentres. Entonces, si estás en iOS, las generaremos en Swift. Si estás en Android, si estás en web, si estás en Flutter, dependiendo de la plataforma en la que te encuentres, generaremos el código para esa plataforma. También tiene una biblioteca de transformación de GraphQL incorporada. Y esta es una biblioteca de directivas que te permiten decorar tu esquema y agregar lógica de autorización adicional. A partir de aquí, puedes definir conexiones. Uno a muchos, muchos a uno, relaciones uno a uno. Puedes definir reglas de autorización. Puedes mapear tus operaciones directamente a través de una función Lambda utilizando la directiva de función, todo tipo de cosas. Hay algunas otras cosas que vienen incluidas con Amplify, como el acceso sin conexión utilizando Amplify Datastore. Pero básicamente, obtienes ayudantes adicionales que vienen con el framework si estás usando Amplify.

Pero la opción que voy a utilizar hoy es AWS CDK. Y AWS CDK es bueno porque te permite escribir tu infraestructura como código utilizando un lenguaje de programación familiar.

Y para mí, eso es TypeScript. Este es el ejemplo con el que voy a trabajar hoy. Y en realidad puedes configurar CDK para que funcione con las bibliotecas de cliente de Amplify. Así que hay una forma de implementar tu API utilizando una salida que creará un archivo configurable que luego puedes usar con tu proyecto de cliente de Amplify. Y eso es lo que también vamos a ver en un momento.

Entonces, la demostración que me gustaría hacer ahora es construir un gateway de API en la nube desde cero utilizando CDK y AppSync. Para hacer eso, voy a ir a mi editor de texto y vamos a comenzar a escribir algo de código. Desde aquí, voy a crear un nuevo directorio llamado API Gateway. Y voy a cambiar a ese directorio. Desde aquí, voy a inicializar un nuevo proyecto de CDK. Así que voy a decir CDK init. Voy a establecer el lenguaje en TypeScript. Y desde aquí, voy a abrir este proyecto en mi editor de texto. Y en este archivo en nuestra carpeta lib donde tenemos este nombre de stack, aquí es donde vamos a escribir nuestro código de CDK. Y cuando estás trabajando con CDK, estás trabajando con diferentes servicios de AWS. Entonces, puedes instalar los constructos y clases para esos diferentes servicios directamente en tu proyecto. Para mí, voy a utilizar AWS Lambda. Así que puedo decir AWS Lambda. Voy a utilizar AppSync. Y también voy a utilizar AWS DynamoDB o Amazon DynamoDB. Y una vez que hayas instalado estos constructos y clases, puedes comenzar a usarlos. Así que voy a construir nuestra API aquí utilizando estos constructos y clases. Lo siguiente que voy a hacer es importar Lambda, DynamoDB y AppSync. Y luego, utilizando estos constructos, podemos comenzar a escribir nuestra API. Muy bien. Lo siguiente que me gustaría hacer es crear una nueva API de AppSync. Y aquí vamos a decir que queremos una nueva API de AppSync.GraphQL, y luego pasas tu configuración. Así, construiremos la API desde cero. Así que voy a decir que quiero que esto sea Cloud API GQL Galaxy.

Luego definimos de dónde proviene este código. Entonces, en este ejemplo, estoy diciendo en una carpeta llamada GraphQL y un archivo llamado schema.graphql. Así que podemos seguir adelante y crear esa carpeta aquí y luego crear ese archivo aquí. Volveremos a eso en un momento.

Luego definimos nuestra configuración de autorización. Por ahora, solo la establecemos como una clave de API y eso básicamente nos dará acceso público.

Para nuestro esquema, voy a crear un esquema que nos permitirá interactuar con dos fuentes de datos diferentes dentro de nuestra API. Las dos fuentes de datos con las que vamos a trabajar son una base de datos DynamoDB y luego la segunda será la API de Unsplash. Entonces, queremos poder obtener imágenes de la API de Unsplash. Para hacer eso, tendremos un tipo de imagen que tiene algunos metadatos sobre la imagen. Tendremos un tipo de URL que tiene metadatos sobre las URLs que se devolverán para cada imagen. Esos son los tipos de datos de Unsplash. Luego tenemos un tipo de publicación y un tipo de entrada de publicación para crear elementos en DynamoDB para un blog. Entonces, el tipo de publicación será para un blog. Y luego tenemos nuestras operaciones para consultas y mutaciones. Entonces, tenemos una consulta de listar publicaciones que escanea la database y trae todo de vuelta. Tenemos una búsqueda de imágenes que recibe una consulta y devuelve un arreglo de imágenes. Y luego tenemos una mutación para crear una publicación que recibe una publicación y devuelve la publicación. Y finalmente, tenemos una suscripción básica para cuando se crea una publicación.

Después de haber definido nuestro esquema, volvemos aquí, tal vez queramos seguir adelante y definir nuestra tabla DynamoDB. Entonces, aquí, la tabla DynamoDB es donde irán nuestras publicaciones. Así que básicamente estamos diciendo que queremos una nueva tabla DynamoDB. La llamaremos Cloud DDB post table, algo así. Y a partir de ahí, ahora podemos agregar nuestra función Lambda, que mapeará nuestras solicitudes de GraphQL desde la API hacia DynamoDB. Entonces, lo que voy a hacer es seguir adelante y crear una función Lambda. Y aquí estamos diciendo que queremos una nueva función Lambda. Le daremos un nombre, como, ya sabes, alguna función Lambda. Tal vez la llame GQL Galaxy function. Estamos configurando algunas cosas básicas como nuestro tiempo de ejecución, dónde estará nuestra función controladora en una carpeta llamada funciones Lambda, nuestro tamaño de memoria y un par de variables de entorno. Entonces, la clave de la API es donde necesitaremos colocar nuestra clave de API para la API de Unsplash.

Ya he configurado esto en un proyecto separado, pero esto sería algo como, ya sabes, x guion xxx, lo que sea. Y finalmente, creamos una data fuente a partir de la API que creamos anteriormente utilizando la función Lambda que acabamos de crear allí, que acabamos de definir allí. Entonces, estamos diciendo que queremos que se cree una data fuente de Lambda llamando a API.addLambda data source. Y luego lo último que queremos hacer es dar algunos permisos. Entonces, vamos a decir que queremos habilitar el acceso a la tabla DynamoDB para nuestra función Lambda, y luego agregamos una nueva variable de entorno para la tabla real que creamos para poder acceder a ella en la función Lambda.

Y luego lo último que queremos hacer es crear nuestros resolvers. Entonces, para los resolvers, veamos aquí. Veamos aquí. Tenemos tres resolvers porque, en nuestro esquema, tenemos tres operaciones, listas, publicaciones, búsqueda de imágenes, y crear publicaciones. Entonces, aquí vamos a mapear nuestras operaciones de GraphQL en esos diferentes campos. Entonces, estamos diciendo que queremos una consulta de listado de publicaciones, una mutación de creación de publicaciones y una consulta de búsqueda de imágenes. Y esto son 66 líneas de código, y si realmente quitamos los comentarios y cosas así, estamos hablando de tal vez 55, 60 líneas de código.

Esto ha desplegado todo nuestro backend. Lo único que necesitaríamos hacer en este punto sería crear nuestro código de función Lambda. Entonces, voy a crear un par de estos archivos solo para mostrarte cómo se ven. Pero, en general, creo que el archivo principal del que aprenderás es este main.ts, y tal vez el searchimages.ts. Entonces, la función principal va a ser el punto de entrada principal. Entonces, aquí es donde recibimos el evento que viene de la solicitud de GraphQL aquí en el evento, y básicamente vamos a tener algunas funciones diferentes con las que podemos operar. Entonces, createPost, listPost, searchimages, y luego el tipo de publicación en sí. Y en el evento, tenemos el nombre del campo, y el nombre del campo básicamente va a ser algo como createPost, listPost, searchimages, lo que sea. Y luego podemos obtener los argumentos del evento llamando a event.arguments. Entonces, cualquier cosa que se haya pasado a la operación está disponible aquí, por lo que podemos llamar a createPosts. Podemos llamar a searchImages, y tenemos esa información de argumento disponible aquí como event.arguments. Y luego lo último que veremos es esta función para crear búsqueda. Entonces, básicamente vamos a tener nuestra consulta principal aquí, donde tenemos nuestra... Veamos aquí. Tenemos nuestra consulta que viene como argumento. Definimos el punto de consulta principal, que es esta API de Unsplash, estableciendo la consulta como la consulta que viene como argumento y la clave de API que proviene de la variable de entorno. Y aquí simplemente llamamos a Axios. Entonces, llamamos a Axios.get, pasando la consulta principal, y devolvemos el array de resultados de datos de respuesta. Y eso es todo. Luego podemos desplegar esto si queremos ejecutando npm run build y cdk deploy. Y esto desplegaría nuestra API. Y lo que obtendríamos sería básicamente este punto de conexión de AppSync. Y tenemos en el panel de control una forma de interactuar con este punto de conexión.

Entonces, podemos ir a nuestro editor de consultas y podemos hacer una consulta de listado de publicaciones para listar nuestras publicaciones. Y en este momento, vamos a obtener un array vacío, así que vamos a crear una nueva publicación. Y ahora deberíamos poder listar las publicaciones. Y esto va a nuestra tabla DynamoDB. Y también tenemos nuestra función de búsqueda de imágenes que interactúa con Unsplash. Entonces, podríamos decir que queremos buscar gatos. Y obtendríamos las imágenes de vuelta y deberíamos poder probar esto. Y debería haber gatos. Eso parece un perro, pero también hay un gato. Probemos una más y luego terminaremos. Entonces, voy a ir a full, a ver si hay gatos aquí. Ahí vamos. Muy bien. Eso es todo. Fue mucho para asimilar, así que espero que hayas aprendido mucho. Si quieres aprender más, ve a la documentación de Amplify, ve a la documentación de AppSync o ve a la documentación de CDK. Todos están listados aquí, pero puedes buscarlos fácilmente. Fácil de encontrar. Así que gracias por ver. Espero que hayas aprendido mucho y espero que disfrutes del resto de este evento.

Gran charla. Tengo un par de preguntas más. Si no te importa escucharlas, puedes irte. No podemos detenerte. Veremos. Veremos. Si hay algo que quiero escuchar y responder, no me importará quedarme. Veremos. Sin preocupaciones. Entonces, dependiste mucho del CDK de Amazon, que es un git de desarrollo en la nube, creo.

¿Sacrificas flexibilidad en tu API escalable al vincularla tan íntimamente con una infraestructura de Amazonbackend? Sí. Entonces, creo que porque la pila que utilicé está utilizando, en realidad el propio servicio está utilizando AWS AppSync. Entonces, cada vez que utilizas un servicio administrado, vas a tener algunas compensaciones, y algunas de esas compensaciones serán buenas y otras serán malas. Algunas de las cosas buenas son que podrás tener esta infraestructura altamente escalable implementada en solo unos minutos, y puedes comenzar rápidamente. No tienes que escribirlo todo desde cero. Las compensaciones son que estás limitado por las API y la funcionalidad y características que proporciona AppSync. Entonces, si hay algo que necesitas y no tenemos, básicamente no podrás obtener esa funcionalidad. Por lo tanto, diría que cuando un cliente está considerando usar AppSync, por ejemplo, uno de nuestros primeros clientes y más exitosos en ayudarnos a escalar, especialmente nuestras suscripciones de GraphQL, fue Ticketmaster. Y analizamos lo que necesitaban del servicio y funcionó muy bien para ellos. Y desde entonces, nos han ayudado a escalar, especialmente nuestras capacidades en tiempo real, a decenas de millones de clientes conectados por un solo punto de conexión de API. Por lo general, les decimos a los clientes, veamos qué necesitas de tu API, de tu servicio. Y veamos si esto va a funcionar. Si va a funcionar, genial. Si no, entonces probablemente deberías usar algo más, tal vez construir tu propia solución personalizada.

Sí, esa es una buena respuesta. No se puede criticar. Hablemos de las pruebas. Entonces, tuvimos un poco de pruebas de desarrollador en la charla. Pero las pruebas de Lambdas a menudo se consideran difíciles, al menos en la convención de la comunidad y las pruebas de GraphQL todavía están un poco menos definidas en comparación con otros tipos de interacción. ¿Cuáles son tus sugerencias para las pruebas de GraphQL Lambdas?

Entonces, usando la aplicación que acabo de construir en realidad, una forma realmente fácil de comenzar a probar de inmediato sería usar el SAM CLI, que es una especie de marco de gestión de aplicaciones serverless que proporciona AWS. Tienen una muy buena CLI para probar funciones serverless. En cuanto a las pruebas de las propias APIs de AppSync, utilizando el servicio en sí, actualmente no hay una buena solución para las pruebas locales reales. Entonces, la mayoría de las veces los clientes tienen un entorno de pruebas para sus características y luego, cuando están satisfechos con su estado, simplemente lo fusionan en su entorno de producción. Pero actualmente no hay una estrategia de pruebas locales para las APIs de AppSync construidas con CDK. Pero usando el enfoque que tomé, en realidad es mucho más fácil de probar localmente que si estuvieras construyendo APIs de AppSync directamente en la consola o algo así porque puedes probar esos resolvers localmente usando el SAM CLI. Y el SAM CLI es una forma realmente sólida de probar funciones serverless en mi opinión.

¿Usar serverless offline es una forma ingenua de intentar probar esto o es demasiado complejo para manejarlo? ¿Pruebas serverless offline? Bueno, no. Probar estas funciones lambda y las respuestas de GraphQL usando el paquete serverless offline. Oh, ¿sabes qué? No lo he intentado. ¿Como desde el framework serverless? Sí, sí. También tienen una forma de ejecutar lambdas localmente. Así es como he creado una superficie de pruebas antes. Correcto. Probablemente sea muy similar al SAM CLI. Diría que probablemente sea muy similar donde básicamente puedes invocar una función pasando un evento y el evento tiene toda la información que esperarías en esa función y luego podrías imprimirlo en tu terminal y cosas así. Creo que ambas opciones son probablemente buenas.

Bueno, vamos a tener una pregunta de Juan. Esto parece estar dirigido a comenzar para evitar gastar tanto tiempo en algo que podría no funcionar, pero ¿se puede migrar a otro sistema después? Supongo que se refiere a la portabilidad de la solución. Entonces, hay dos partes en la solución que acabo de mostrar. Diría que las dos partes principales son la base de datos que implementamos, que en mi ejemplo es DynamoDB, y luego está la lógica empresarial real y el esquema que forma parte de GraphQL, diría yo, Land. Y si quisieras tomar lo que acabamos de construir y luego migrarlo a otra solución, tendrías que, ya sabes, podrías trasladar tu esquema y podrías trasladar incluso esas funciones y configurarlo de esa manera. Pero tendrías que reescribir una cantidad significativa de tu aplicación. Tendrías que reconstruir eso. Pero diría que sí, es portable.

Básicamente, puedes trasladar esto a una implementación personalizada, tal vez alojada en AWS porque DynamoDB, diría que el mayor bloqueo con lo que acabo de mostrar es DynamoDB, que es una base de datos específica de AWS. Entonces, si quisieras trasladarlo a algo como Google u otra base de datos personalizada, creo que el principal desafío que tendrías sería, ya sabes, extraer esos datos de esa base de datos y luego transformarlos en lo que sea necesario para tu próxima base de datos y colocarlos allí y hacerlo, especialmente si estás en producción, de una manera que no dé ninguna oportunidad de arruinar tus datos. Sí, la persistencia siempre es la parte más difícil de este tipo de servicios. Me gusta mucho que de muchas maneras GraphQL sea casi como una función pura del resolutor. Pones algo, sacas algo. Sabes, lo realmente interesante, sin embargo, de DynamoDB y una de las cosas que muchos clientes hacen es que hay una forma de activar una función para cualquier actualización en DynamoDB. Entonces, básicamente, lo que los clientes a menudo hacen es tener básicamente otra base de datos donde almacenan una copia de esta base de datos y pueden necesitarla por ciertas razones, como querer tener un tipo diferente de patrón de acceso a los datos. Por ejemplo, si necesitas consultar los mismos datos utilizando algo como Elasticsearch, que te brinda capacidades de consulta más potentes en cosas como geolocalización y cosas así, podrías automáticamente tener una réplica de esos datos en otra base de datos. Y en realidad sucede automáticamente si configuras el disparador. Un disparador básicamente enviaría cualquier actualización, por lo que cada vez que alguien coloque, actualice o elimine algo, tendrías ese fragmento de datos enviado a una función, y luego podrías tomar esos datos y escribir en otra base de datos. Entonces, si quisieras tener una copia en una base de datos SQL, podrías consultar los mismos datos no solo desde una base de datos NoSQL, sino también desde una base de datos SQL o Elasticsearch o donde quieras que esté. Es como una capa de persistencia impulsada por eventos. Exactamente.

Genial. Una pregunta de Dude RSM. Hola, Nadir, ¿cómo describirías la curva de aprendizaje al intentar usar AppSync para crear una API DQL? Creo que en el pasado era una curva de aprendizaje bastante empinada. Creo que muchas de las herramientas y cosas que están saliendo ahora lo están haciendo mucho más fácil. Por ejemplo, solía haber un nivel de resolutor que tenías que usar llamado VTL, Velocity Templating Language, que es un lenguaje completamente nuevo y muy difícil de probar. Pero ahora, con el lanzamiento de los Resolutores Directos de Lambda, básicamente lo que uso, puedes simplemente escribir toda tu lógica de negocio en JavaScript.

Entonces, la curva de aprendizaje para AppSync es simplemente comprender cómo escribir la capa de implementación que estás utilizando. En mi ejemplo, uso CDK y escribimos una API completa y unas pocas docenas de líneas de código. Pero también podrías usar algo como Serverless Framework o podrías usar algo como la CLI de Amplify, que lo escribe por ti. Solo te hace una serie de preguntas y te guía. Y luego respondes sí, no y lo pones en tu esquema. Y luego nosotros escribimos todo eso por ti. Escribiremos todos esos resolutores por ti, y escribiremos toda la lógica de negocio para las operaciones de crear, leer, actualizar y eliminar. Y luego puedes modificar eso a tu gusto.

Diría que la curva de aprendizaje ha mejorado. Y luego, a principios del próximo año, en el primer trimestre de 2001, lanzaremos una actualización realmente masiva para el servicio de AppSync que lo hará aún más fácil. Estamos viendo una alta demanda de ciertas cosas ahora que hemos aumentado el número de clientes que tenemos. Así que podemos priorizar mejor estas cosas. Tenemos un lanzamiento muy interesante que saldrá en el primer trimestre del próximo año, que reducirá aún más la curva de aprendizaje. Diría que en este momento, desde que lanzamos ese nuevo soporte para resolutores directos de Lambda hace aproximadamente un mes o dos, eso redujo significativamente la curva de aprendizaje, y luego se reducirá aún más en un futuro cercano.

Bueno, sabes cómo vender. Nos has dejado en suspenso. Sí. Bueno, manténganse atentos. Ya sabes, sígueme en Twitter. Si aún no lo haces, probablemente me verás hablar de ello y hacer muchas cosas al respecto. Yo sé que lo haré. Muy bien. Esto completa nuestras preguntas para ti en esta encantadora noche. Así que pongan sus gorras de emojis juntas para Nader. Vaya, siempre olvido. Lo siento mucho. No, lo hiciste bien la primera vez. Nader. Sí. Sabía que dudaba de mí mismo y no debería haberlo hecho.

Y sí, muchas gracias por tu maravillosa charla. Y tendremos, creo que tienes un plan de charla en la sala de los oradores después, ¿verdad?

Sí, lo tengo. Lo tengo. Y gracias por invitarme. Fue realmente bueno hablar contigo. Sé que nos conocimos en Londres hace un tiempo. Espero poder verte de nuevo en persona porque he oído que eres una persona divertida para salir de fiesta. Así que espero poder hacer eso contigo una noche.

Eso fue increíble. Siempre estás invitado. Suena bien. Hasta luego, todos.