Arquitecturas Avanzadas de GraphQL: Event Sourcing y CQRS sin servidor

Es bueno que te diviertas. Estoy aquí para cambiar eso. Me encantan las historias, por supuesto, como a todos. No soy muy bueno contando historias. Pero afortunadamente, con la IA, puedo pedirle que finja ser algún escritor famoso o algo así y me ayude.

Pero hoy estoy aquí para contarles algunas historias. La primera historia es sobre GraphQL. Muchos de ustedes conocen GraphQL y muchos de ustedes conocen una aplicación llamada Facebook. Ahora probablemente sea utilizada principalmente por nuestros padres y cosas así. Pero en algún momento, la aplicación de Facebook construyó una aplicación móvil. Era solo una vista móvil de esa aplicación que estaba empaquetada dentro de la aplicación móvil como una vista web. Y en realidad alimentaron los data a esa aplicación como HTML. Por lo tanto, se renderizó en algún lugar en el servidor y se envió como un HTML completo a la aplicación.

Y luego, hace un poco más de 10 años, hubo un gran titular en todas partes en las noticias de front-end JavaScript que decía algo así como Mark Zuckerberg. Dijo que su mayor error en ese momento fue apostar demasiado por HTML5. Y luego decidieron reescribir su aplicación y construir una aplicación móvil real en ese momento con código nativo y todo. Pero su gran desafío era cómo servir data a esa aplicación. Intentaron usar REST, luego FQL que era Facebook Query Language o algo así. Y luego tuvieron un problema básicamente con las diferencias entre los data que querían presentar dentro de la aplicación y los data que devolvía el servidor.

Ahora eso probablemente no sea un gran problema porque nuestro Internet es mucho más rápido, pero en ese momento en lugar de simplemente obtener publicaciones y cosas así, obtener respuestas completas y hacer muchas solicitudes fue un poco problemático. Así que inventaron una herramienta genial llamada GraphQL donde básicamente puedes pedirle a tu servidor datos específicos y él puede darte los datos. Funciona así, defines los datos que quieres. Por ejemplo, quiero un usuario con IDs específicos pero no quiero todo sobre ese usuario, solo quiero algunas cosas específicas y quiero obtener una imagen con un tamaño específico y tal vez los primeros 5 amigos de esa persona y luego el servidor me dará JSON en el mismo formato, lo cual es increíble. Y otra cosa increíble sobre GraphQL es que se llama GraphQL y todavía se llama GraphQL. Lo genial es que defines la forma de esos datos, tienes una jerarquía que ayuda a GraphQL a saber qué datos cargar primero y cosas así, es fuertemente tipado lo que te ayuda a navegar por ese esquema y todo fácilmente. Es un protocolo, no realmente una forma diferente de escribir todo el back-end del servidor o lo que sea. Básicamente solo define las formas de los datos y las reglas por las que funciona. Y otra cosa genial fue que obtuviste documentación de inmediato con esa introspección del esquema, puedes preguntarle a GraphQL, oye, dime qué puedo consultar para un usuario y cosas así. Algo que no estoy seguro si es bueno o malo es que no tiene versiones. Básicamente no tiene versiones.

Es necesario ser compatible con versiones anteriores en un servidor porque el frontend puede solicitar cualquier cosa que esté disponible dentro de ese esquema. Antes de GraphQL, una aplicación funcionaba, y aún a menudo funcionan de tal manera que envían una solicitud, luego obtienen una respuesta, luego solicitan otra cosa utilizando algo de la primera respuesta y luego consultan la tercera cosa. Por ejemplo, quieres obtener usuarios de tu base de datos, pero luego quieres obtener sus imágenes de, digamos, Amazon S3 o algo así, y finalmente quieres obtener algunas analíticas de alguna tercera herramienta o algo así.

GraphQL básicamente hizo algo que teníamos antes de Ajax y todo eso, que es básicamente decirle al servidor lo que queremos. El servidor hará todas las cosas y te devolverá los datos, solo que no en HTML. Por lo tanto, los tipos son solo tipos. Defines qué campos tienes y cosas así. Luego defines el esquema. Por ejemplo, tengo algunas consultas aquí, y cada consulta define sus atributos y luego los valores de retorno y cosas así, y luego escribo algo llamado Resolver, que básicamente le dice a mi backend cómo obtener esos datos. El Resolver puede ser cualquier cosa básicamente. Puede leer los datos de una base de datos o consultar alguna API o lo que sea. Realmente no importa. Cuando escribes una consulta, GraphQL básicamente analiza esa consulta, valida que todo esté bien y, cuando todo está bien, ejecuta ese Resolver por nosotros, obtiene los datos, y luego empaqueta el resultado de la manera que queremos. GraphQL admite consultas, que es básicamente una forma de obtener los datos, mutaciones, que es una forma de cambiar algo en el lado del servidor, y suscripciones, que nos brindan actualizaciones y cosas así en tiempo real.

Hoy hablaremos sobre arquitecturas avanzadas de GraphQL, por ejemplo, serverless event sourcing con CQRS, y sé que hay muchas cosas aquí, pero explicaré cada una de ellas.

Permítanme contarles una historia sobre serverless. ¿Quién utiliza serverless en algún momento? El mayor problema con serverless es su nombre, porque causa mucha confusión y nadie sabe cuál es el origen de ese nombre. Probablemente lo primero que vimos en Internet fue algún artículo en 2012, hace unos 11 años más o menos, que decía que el futuro de todas las aplicaciones de software es serverless, y serverless en ese contexto era algo ligeramente diferente. Luego, hace casi 10 años, AWS anunció algo llamado AWS Lambda, que es básicamente la capacidad de escribir una función, que puede ser una función de JavaScript como node.js, y luego adjuntar algún tipo de disparador a esa función, como el gateway de API que se lanzó un año después. Cada vez que hay una solicitud a esa API, alguna función se activará y responderá a básicamente tu solicitud. ¿Quién está usando Vercel aquí? Bueno, probablemente todos ustedes están usando algunas funciones de Lambda en segundo plano. Al menos en algún momento, estaban usando funciones de Lambda.

Entonces, mi amigo explicó los términos de serverless. Aún de la mejor manera, como hace mucho tiempo, dijo que serverless es serverless de la misma manera que Wi-Fi es inalámbrico. Hay cables en algún lugar en el fondo. Y cuando uso mi teléfono, no necesito tener un cable conectado a él. Pero hay un enrutador en algún lugar que tiene cables y cosas así. Estos simplemente no son mis problemas. Es lo mismo con serverless. Y serverless se puede aplicar a muchas cosas. No solo a esa parte de la computación. Ahora tienes bases de datos, buses de mensajes y cosas así. Ya no tengo una buena definición de serverless. Pero la cosa pura de serverless era algo que escala automáticamente cuando lo necesitas escalar, donde pagas por solicitud. Entonces solo estás pagando por las cosas que realmente estás usando. No estás pagando nada si nadie está usando tu aplicación. Y está completamente administrado por tu proveedor de servicios. Serverless es bueno para muchas cosas. Por ejemplo, aplicaciones impulsadas por eventos. Entonces, donde sea que haya algún tipo de evento, ese evento puede ser como una llamada de API, IoT que envía algo, no importa realmente. Siempre que tengas algún tipo de evento, serverless es decente para eso. Es bueno para equipos que se mueven rápido porque estás construyendo funciones pequeñas y puedes cambiar una función sin afectar todo el sistema y cosas así, es bueno cuando no puedes predecir tu carga de trabajo, cuando a veces hay más usuarios que usan tu aplicación y luego en algún momento no hay nadie, es realmente bueno para eso. Y en realidad es bueno para muchas aplicaciones porque al final, serverless es como una infraestructura administrada. Entonces, otra persona está ejecutando nuestros servidores, no necesitamos preocuparnos por eso, al menos no tanto como antes.

Y sé que hay muchas personas que lo hacen mucho mejor que yo. Bueno, hay algunos casos en los que serverless no es tan bueno. Recientemente, Amazon Prime Video dijo que serverless ya no les funciona. Supongo que encontraron un escenario en el que no les funciona. Los chicos de Basecamp a menudo hablan de que los servidores normales son mucho mejores, pero básicamente si tienes tareas de larga duración, si necesitas una latencia realmente baja y cosas así, o si tienes hardware específico o data jurisdicciones, probablemente quieras usar algo diferente, ya sea containers o lo que sea. Pero a quién le importa eso? Serverless fue y sigue siendo bueno para prototipos.

Entonces usamos serverless hace mucho tiempo para construir un prototipo. Y mi prototipo funcionaba así. Quería una pequeña aplicación de PTO que me permitiera solicitar un permiso. Y luego mi gerente dentro de Slack recibe mi solicitud. Pueden hacer clic y aprobar mi permiso o lo que sea. Y probablemente debería presentarme antes de continuar. Mi nombre es Slobodan y trabajo como CTO y cofundador de Vacation Tracker. Esa cosa no es como impulsada por IA, es solo la solicitud de PTO. También soy coautor de aplicaciones serverless con NodeJS, Booq, AWS Serverless Hero, y organizo algunos meetups en Belgrado, Serbia.

Bueno, estaba trabajando con esa aplicación llamada Vacation Tracker, y era un prototipo temprano. Pero en algún momento la gente comenzó a usar nuestras aplicaciones, así que nuestra aplicación creció. Pero el problema era que con el uso de nuestra aplicación, cuando nuestra aplicación se convirtió en una aplicación real, entonces nuestros problemas se convirtieron en problemas reales. Y uno de los grandes problemas era que estábamos almacenando el estado de la aplicación dentro de una database. Por ejemplo, tengo 10 días de PTO restantes para este año. Pero luego muchas cosas pueden cambiar ese estado. Y en algún momento, por ejemplo, si alguien me mueve a otra ubicación, mi gerente me da dos días más, pero luego solicito algunos días, pero luego alguien edita mi solicitud y hace muchas cosas locas. Ya no estábamos seguros de cuál era el estado correcto de la aplicación. Así que buscamos una solución para nuestro problema y afortunadamente siempre hay una antigua solución para la mayoría de los nuevos problemas a los que nos enfrentamos. Así que déjenme hablarles de algo llamado event sourcing. Y sé que esto es principalmente cosas de back-end, pero estoy seguro de que muchos de ustedes han escuchado sobre Redux. ¿Quién ha usado Redux? Perfecto, genial. Entonces, cómo funciona Redux, es como si enviaras algunas acciones o lo que sea, y luego estas acciones pasan por un reductor y generan un estado. Y luego, cuando envías una nueva acción, el reductor genera un nuevo estado y luego la tercera acción genera el tercer estado. Y luego, cuando lees el estado desde la interfaz de usuario, realmente no te importan los eventos.

Solo lees el estado. Pero si vas a Redux DevTools, puedes viajar a través de la historia de estos eventos y ver el estado diferente como punto y cosas así. Bueno, a alto nivel, Redux tiene la misma idea que el event sourcing. Hay algunas diferencias, lo que sea, pero es como si el event sourcing no fuera más que básicamente Redux implementado en el front-end. Así que queríamos hacer algo similar en nuestra aplicación. Y la definición de event sourcing es básicamente asegurarse de que todas las aplicaciones modificadas en todos los eventos se almacenen como una secuencia. Entonces, en algún momento, puedes consultar estos eventos, generar algún tipo de estado actual, pero también viajar a través de la historia de estos eventos y ver cuál es el nuevo estado y cosas así. Esta es la solución perfecta para nuestro problema porque puedo almacenar cada evento en nuestra secuencia como un evento. Y si algo cambia, podemos generar el estado nuevamente. Entonces, hay otra cosa llamada CQRS, o Command Query Responsibility Segregation, que suena realmente aterrador, pero te mostraré en unos segundos que no es tan aterrador. A menudo se utiliza junto con el event sourcing. No es necesario que vaya junto con él, pero a menudo están conectados. Nuevamente, es una idea antigua, como de hace 35 años o algo así, más antigua que algunas personas en esta sala, casi más antigua que yo. Comenzó como Command Query Separation, como una idea. La idea era que en lugar de construir una gran aplicación donde tu consulta puede cambiar el estado de la database, básicamente divides la parte de lectura y la parte de escritura. Cada vez que quieras actualizar algo en tu aplicación, simplemente haces esa actualización y no devuelves nada. Cada vez que quieras leer los data que no afecta tu aplicación de ninguna manera, luego evolucionó a algo llamado Command and Query Responsibility Segregation o CQRS, que básicamente utiliza la misma definición que esto. Y la única diferencia es que básicamente define dos objetos diferentes, por lo que tu comando y el estado que estás leyendo no están en la misma forma en absoluto. Entonces, tu comando es algo como una acción en Redux. Básicamente, el estado que estás leyendo es como el estado en Redux, no son completamente idénticos. Y funciona de manera muy similar a la cosa en Redux. Entonces, básicamente, cada vez que quieras enviar algún comando, pasa por algún modelo de comando o reductor que almacena el evento en algún almacenamiento, pero también crea una representación actual de tu estado de aplicación en algún lugar diferente, como una base de datos diferente o lo que sea. Luego, cada vez que quieras leer tus data, simplemente vas a esa tabla de caché o lo que sea y lees esos data. Por ejemplo, tu cuenta bancaria funciona de la misma manera. Tienes diferentes transacciones y todo lo que te importa es el saldo de tu cuenta en cualquier momento. Realmente no quieres revisar cada transacción todo el tiempo. Bueno, una de las cosas importantes sobre CQRS es que debido a su naturaleza y la forma en que funciona, tiene una consistencia eventual. ¿Qué significa eso? Cuando envío un comando y leo la cosa del estado inmediatamente, existe la posibilidad de que no tenga el estado más reciente, que algo funcionará con ese nuevo evento en segundo plano. Entonces, CQRS es un poderoso patrón de architecture que te ayuda con algunas partes específicas de tu aplicación, pero no es para todo dentro de tu aplicación. Si estás trabajando, por ejemplo, con publicaciones de blog, está bien almacenar la publicación del blog en el fondo como un estado normal en lugar de una serie de eventos, a menos que quieras hacer algo específico como poder retroceder en la historia y cosas así.

A menudo quieres usar estas cosas en parte de tu aplicación, no todo. Pero volvamos a esta definición. Y si observamos esta definición, habla de consultas y también comandos, pero dice que los comandos también se llaman modificadores o mutadores, lo que me da una excelente idea, o tal vez no excelente, pero una idea.

Si tenemos consultas y mutadores o comandos en CQRS y suscripciones de consulta y mutaciones en GraphQL, tal vez estén relacionados de alguna manera que pueda simplemente usar las consultas de GraphQL como consultas y las mutaciones de GraphQL como comandos.

Permíteme contarte sobre lo que estábamos construyendo. Y nuevamente, gracias a GPT por ayudar con estas diapositivas. Esto es lo que queremos construir. Queremos tener algún tipo de API de GraphQL que tenga un comando aquí con algún tipo de resolutor o reductor, lo que sea, que almacene algunos eventos en esa base de datos de eventos, donde básicamente cada evento se almacena tal como se envía.

Lo enviamos y luego queremos tener consultas, que básicamente nos permite básicamente, oh, hay un error tipográfico aquí, pero lo siento por eso. Estas cosas en la parte inferior son consultas donde queremos leer los datos de la base de datos como un estado, no como una serie de eventos. Entonces, lo que podemos hacer, básicamente, es enviar una mutación de GraphQL, esa mutación puede ir a ese resolutor o reductor o lo que sea. Luego almacenar algo dentro de esa base de datos de eventos, algún evento ocurrió. Y luego puede crear una proyección o reducir eso a un estado actual y almacenar ese estado actual en alguna otra base de datos. Cada vez que un usuario quiera leer algo de mi aplicación, simplemente puede ir y leerlo desde esa tabla de caché básicamente. Si elimino esta tabla en la parte inferior, simplemente puedo reproducir todos los eventos y obtener el mismo valor. Entonces, el punto extra aquí son las suscripciones porque esta no es una aplicación síncrona, básicamente el usuario en el front-end no sabe cuándo termina el proceso. Lo bueno de GraphQL es que define suscripciones, lo que básicamente nos permite enviar un mensaje en tiempo real de vuelta a nuestro front-end y decirle al usuario: `hey, esto ha terminado`. Así que intentemos construir esto con AWS. Lo haré rápidamente porque puedes implementarlo con muchas cosas diferentes. Pero permíteme guiarte a través de este proceso.

Intentemos hacerlo sin servidor para que esté completamente administrado, no necesitamos hacer nada por nosotros mismos. Primero, necesitamos una capa de GraphQL. Usaremos algo llamado AWS AppSync para eso. AppSync es un GraphQL completamente administrado y escalable por AWS. Te brinda suscripciones listas para usar. Se integra con muchos servicios diferentes, por lo que solo necesitas escribir una pequeña pieza de integración llamada Resolutor. Con JavaScript ahora, había un lenguaje extraño llamado BTL antes de eso, y escala muy bien. No pagas nada al principio hasta que tienes muchos usuarios y cosas así. Luego queremos almacenar estos eventos y estos estados actuales en algún lugar, podemos usar algo llamado DynamoDB, que es una base de datos NoSQL administrada y escalable por AWS. Es algo así como Mongo, pero ligeramente diferente.

Tiene una latencia realmente baja. Solo pagas por las cosas que realmente utilizas. No pagas si nadie está usando tu aplicación, excepto por algún almacenamiento de datos, y puede manejar millones de solicitudes por segundo. Probablemente no lo necesites en las primeras etapas, pero es bueno tener esa escalabilidad y puedes transmitir los datos, lo cual es genial porque la base de datos misma puede decirte cuándo se almacenan nuevos datos o cuando los datos cambian.

Por supuesto, necesitaremos algo para crear una proyección a partir de estos eventos. Podemos usar esa función AWS Lambda para eso. Lambda es, como mencioné, solo una función que es administrada y escalable. Es económico. Cuesta alrededor de $0.20 por millón de solicitudes o algo así. Admite muchos lenguajes, incluyendo Node.JS y muchos otros.

Ahora, si volvemos a MyDiagram, podemos usar AppSync para esta parte. Nada ha cambiado aquí. Podemos almacenar los data en ese DynamoDB. Lo bueno de DynamoDB es que puede decirle a Lambda en segundo plano, hey, algo nuevo ha cambiado en la database. Y luego podemos crear esa proyección completamente en segundo plano. Y podemos usar esa función de Lambda para devolver el evento de suscripción a nuestro usuario. Es lo mismo con la lectura de los data. Y eso es básicamente todo.

Ahora, es difícil usar una función de Lambda para muchos eventos. Ahora tenemos muchos, muchos eventos en la aplicación, por lo que necesitamos algún tipo de bus de mensajes que divida eso en múltiples funciones más pequeñas. Usamos algo llamado EventBridge, que es básicamente un bus de eventos que envía un mensaje a algún lugar, y luego diferentes funciones de Lambda pueden despertar y responder a eso. Y lo bueno de estos servicios es que tienen almacenamiento y reproducción para los eventos, y todo funciona algo así al final. Entonces almacenamos los data. Los data van a través de algún EventBridge, y ese EventBridge sabe exactamente qué funciones deben manejar ese tipo de evento, y todo lo demás es igual.

Para las consultas, nada cambia. Es lo mismo. Si tienes una carga alta, puedes usar una cola delante de todo. Hay una cola, la famosa cola en AWS llamada SQS, que es escalable nuevamente, y tu uso de papel y cosas así. Entonces puedes poner una cola delante de tu database y todo, para que si tienes un pico enorme, no se bloquee tu aplicación ni nada por el estilo. Todas estas cosas se escalan, incluso sin una cola, pero en algún momento, a una gran escala, probablemente necesitarás eso. Así que veamos esto en la práctica, y terminaré con eso. Para nosotros en Vacation Tracker, funciona algo así. Nuevamente, es muy similar a lo que te dije. Se almacena en una database, se invocan algunas funciones y algunos eventos a algún puente de eventos, bus de eventos, toda la lógica empresarial hace algo, se almacena una versión en caché en alguna database y se utiliza otro bus de eventos para notificar al front-end o a Slack o a Microsoft Teams. Y cuando lees los data, es fácil. Simplemente usas GraphQL o usas la API REST para Slack porque Slack no sabe cómo trabajar con GraphQL. Beneficios, tenemos una aplicación completamente administrada. El último evento, donde alguien trabajó después de horas de trabajo para solucionar un error o algo así, fue hace más de dos años. Así que es estable. Es fácil rastrear todos los cambios.

Menos código porque solo estamos utilizando servicios para hacer estas cosas y tenemos un mejor control y todo es realmente escalable. Desventajas, tenemos muchos nuevos servicios que todos necesitan conocer. Es difícil rastrear los eventos porque tienes muchos servicios diferentes por donde pasa el evento . La complejidad de la aplicación es un poco mayor. Y sí, hay algunos desafíos al escribir la aplicación. El modelado de data es realmente difícil con DynamoDB. Afortunadamente, Chaijupiti puede ayudarte con eso. Y lo bueno es que puedes usar TypeScript para eventos, esquemas y todo y básicamente redondear todo en una gran solución.

Tuvimos diferentes desafíos con el desarrollo, pruebas, monitoreo, seguridad, pero hemos superado todos ellos. Si quieres saber más sobre estas cosas, no dudes en acercarte después de la charla. No tengo suficiente tiempo para hablar de estas cosas ahora. Pero lo último genial es que es realmente barato. Así que tenemos 12 entornos que son idénticos y todo cuesta un poco más de $1000 al mes. Y esa aplicación genera mucho más que eso.

En lugar de un resumen, quiero terminar con dos citas. Primero, la cita es que debemos darnos cuenta de que algunas reglas simples pueden convertirse básicamente en algo mucho más complicado y construir cosas realmente complicadas en el futuro. Básicamente, algo que comienza muy simple con el tiempo puede crecer y volverse mucho más complicado y resolver un problema realmente bueno. Y no necesitas comenzar con cosas complejas. Siempre debes comenzar con algo simple. Y otra cosa que realmente cito, que realmente me encanta, es que debemos hacer que algo funcione primero. Y luego, si tenemos tiempo, lo haremos hermoso. Y finalmente, si realmente, realmente es necesario, lo haremos rápido. El noventa por ciento del tiempo, si lo hacemos hermoso en algún momento, será automáticamente rápido. Así que simplemente hazlo hermoso.

Eso es todo por mi parte. Esto es lo de la IA y el cofundador de IA que se mencionó al principio. Y esto es básicamente un producto que estoy construyendo que no es de IA. Gracias. Eso es todo. Si tienes alguna pregunta.

Muy bien, alguien preguntó cómo se pueden regenerar las tablas de proyección a partir de la tabla de eventos cuando la lógica de proyección, es decir, el código de Lambda, se actualiza en el medio. Básicamente, almacenamos cada versión de Lambda porque no pagas por la función de Lambda si nadie la está utilizando. Es muy económico tener una Lambda para cada versión. Entonces, si nuestra estructura de eventos cambia, básicamente no actualizamos una Lambda, en su lugar, creamos una nueva función de Lambda y simplemente la conectamos para escuchar una nueva versión del evento.

Genial, genial. En realidad, eso es muy fácil porque te da más código, pero eventualmente ya no mantienes las versiones antiguas de cada función de Lambda. Así que, sí.

Eso es increíble, eso es increíble. Tenemos otra pregunta que acaba de llegar. ¿Cómo manejas la trazabilidad? La trazabilidad, sí, sí. Necesitas tener algún tipo de ID de correlación que atraviese todas las partes del sistema. Y luego hay herramientas específicas que puedes usar, incluyendo, por ejemplo, como X-ray, que puede rastrear diferentes cosas a través de los servicios de AWS, pero también puedes usar cosas simples como simplemente registrar ese ID de correlación y luego usar algo llamado CloudWatch log insights para buscar lo mismo en todas las funciones.

Eso es genial. Ahora sé que algunas personas tienen más preguntas que surgen, pero pueden acercarse y encontrarlo. También estará en la sala de preguntas y respuestas de los oradores. Así que si estás en línea, también podrás hacer más preguntas, pero muchas gracias. Muchas gracias. Definitivamente una de las últimas pero no menos importantes charlas del día, realmente te lo agradezco. Gracias.