Arquitecturas Avanzadas de GraphQL: Serverless Event Sourcing y CQRS

Es bueno que te estés divirtiendo. Estoy aquí para cambiar eso. Así que me encantan las historias, por supuesto, como a todos. No soy tan bueno contando historias. Pero afortunadamente con la IA, puedo simplemente pedirle que finja ser algún escritor famoso o algo así y ayudarme.

Pero estoy aquí hoy 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 más utilizada por nuestros padres y cosas así. Pero la aplicación de Facebook en algún momento 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 alimentaban los datos a esa aplicación como HTML. Así que se renderizaba en algún lugar del servidor y se enviaba 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 artículos de JavaScript que era como por 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 datos a esa aplicación. Intentaron usar REST, luego algo de FQL que era Facebook Query Language o lo que sea. Y luego tuvieron un problema básicamente con las diferencias con los datos que querían presentar dentro de la aplicación y los datos que devolvía el servidor.

Ahora eso probablemente no es un gran problema porque nuestro Internet es mucho más rápido, pero en ese momento en lugar de solo obtener publicaciones y cosas así, obtener respuestas completas y hacer muchos viajes de ida y vuelta era un poco problemático. Así que idearon una herramienta genial llamada GraphQL donde básicamente puedes pedir a tu servidor datos específicos y te puede dar los datos. Funciona algo así, es como 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 que se llamaba GraphQL y todavía se llama GraphQL. Lo genial es que defines esa forma de datos, tienes jerarquía que ayuda a GraphQL a saber qué datos cargar primero y cosas así, es fuertemente tipado que te ayuda a navegar por ese esquema y todo fácilmente. Es un protocolo, no realmente una forma diferente de escribir un back-end del lado 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 ese esquema de introspección puedes pedir a GraphQL, oye, dime qué puedo consultar para el usuario y cosas así. Algo que no estoy seguro si es bueno o malo es que no tiene versiones. Básicamente no tiene versión.

Necesitas ser compatible hacia atrás en un servidor porque el front end puede pedir cualquier cosa que esté disponible dentro de ese esquema. Antes de GraphQL, una aplicación funcionaba, y todavía a menudo funcionan de una manera que envían una solicitud, luego obtienen una respuesta, luego piden otra cosa usando algo de la primera respuesta, y luego consultan una 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 por el estilo.

GraphQL básicamente hizo algo que teníamos antes de Ajax y todo, que es básicamente decirle al servidor lo que quieren. El servidor hará todas las cosas y te devolverá los datos, solo que no en HTML. Así que los tipos son solo tipos. Defines qué campos tienes y cosas como estas. Luego defines el esquema. Por ejemplo, tengo algunas consultas aquí, y cada consulta define sus atributos y luego 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. Resolver puede ser básicamente cualquier cosa. 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 luego 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 dan actualizaciones y cosas como estas en tiempo real.

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

Déjame contarte una historia sobre serverless. ¿Quién usa serverless en algún momento? El mayor problema de serverless es su nombre, porque causa tanta confusión y todo, y nadie sabe cuál es el origen de ese nombre. Probablemente lo primero que vimos en internet fue de algún artículo en 2012, como hace 11 años o así, 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 una capacidad para 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 API gateway que se lanzó un año después. Siempre 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, todos ustedes probablemente están usando algunas funciones Lambda bajo el capó. Al menos en algún momento, estaban usando funciones Lambda.

Así que mi amigo explicó los términos de serverless. Aún de la mejor manera, como hace mucho tiempo, dijo que serverless es serverless en la misma forma en 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 router 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 es solo esa parte de computación. Ahora tienes bases de datos, buses de mensajes y cosas como estas. Ya no tengo una buena definición de serverless. Pero la cosa pura de serverless era algo que se escala automáticamente cuando lo necesitas escalar, donde pagas por solicitud. Así que estás pagando solo por las cosas que realmente estás usando. No estás pagando nada si nadie está usando tu aplicación. Y es completamente gestionado por tu proveedor de servicios. Serverless es bueno para muchas cosas. Por ejemplo, aplicaciones impulsadas por eventos. Así que dondequiera que haya algún tipo de evento, ese evento puede ser como una llamada API, IoT que envía algo, realmente no importa. 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 pequeñas funciones y puedes cambiar una función sin afectar todo el sistema y cosas como estas, es bueno cuando no puedes predecir tu carga de trabajo, cuando a veces hay más usuarios usando 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 gestionada. Así que alguien más está ejecutando nuestros servidores, no necesitamos preocuparnos por eso, al menos no tanto ya.

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

Así que usamos serverless hace mucho tiempo para construir un prototipo. Y mi prototipo funcionaba algo 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, esa es la cosa de solicitud de PTO. También soy coautor de aplicaciones serverless con NodeJS, Booq, AWS Serverless Hero, y estoy organizando 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 app se convirtió en una app real, entonces nuestros problemas se convirtieron en problemas reales. Y uno de los grandes problemas era como, estábamos almacenando un estado de la aplicación dentro de la base de datos. 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 como 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 vieja solución para la mayoría de los nuevos problemas que enfrentamos. Así que déjame contarte sobre una cosa llamada event sourcing. Y sé que estas son principalmente cosas de back-end, pero estoy seguro de que muchos de ustedes han oído hablar de Redux. ¿Quién ha usado Redux? Bien, perfecto. Así que cómo funciona Redux, es como si estuvieras enviando algunas acciones o lo que sea, y luego estas acciones pasan por algún reductor y generan algún estado. Y luego cuando envías una nueva acción, entonces el reductor genera un nuevo estado y luego la tercera acción genera el tercer estado. Y luego cuando lees el estado desde la UI, 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 un alto nivel, Redux tiene la misma idea que event sourcing. Hay algunas diferencias, lo que sea, pero es como, event sourcing no es nada más que básicamente Redux implementado event sourcing en el front end.

Así que queríamos hacer algo similar en nuestra aplicación. Y la definición de event sourcing es que básicamente asegura que todas las aplicaciones cambiadas en todos los eventos se almacenen como una secuencia. Así que 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.

Así que hay otra cosa llamada CQRS, o Command Query Responsibility Segregation, que suena realmente aterrador, pero te mostraré en unos segundos, no es tan aterrador. A menudo va con event sourcing. No necesita ir con él, pero a menudo está conectado. Nuevamente, es una idea antigua, como de 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 pueda cambiar el estado de la base de datos, básicamente divides la parte de lectura y la parte de escritura. Siempre que quieras actualizar algo en tu aplicación, simplemente haces esa actualización y no devuelves nada. Siempre que quieras leer los datos que no afectan tu aplicación de ninguna manera, entonces evolucionó a algo llamado Command and Query Responsibility Segregation o CQRS, que básicamente utiliza la misma definición que esta. Y la única diferencia es que básicamente, define dos objetos diferentes, así que tu comando y el estado que estás leyendo no están en la misma forma en absoluto.

Así que 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. Así que básicamente, cada vez que quieres 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 en una base de datos diferente o lo que sea. Luego, cada vez que quieres leer tus datos, simplemente vas a esa tabla de caché o lo que sea y lees esos datos. 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 pasar por 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 consistencia eventual. ¿Qué significa eso? Cuando envío un comando y leo la cosa del estado inmediatamente, hay una posibilidad de que no tenga el estado más reciente, que algo trabajará con ese nuevo evento en el fondo. Así que CQRS es un patrón de arquitectura poderoso 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 con, por ejemplo, publicaciones de blog, está bien almacenar la publicación de 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 ir atrás en la historia y cosas así.

Así que a menudo querrás usar estas cosas en parte de tu aplicación, no en todo. Pero volvamos a esta definición. Y si echamos un vistazo a esta definición, está hablando 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 de alguna manera relacionados de una forma que pueda simplemente usar consultas de GraphQL como consultas y mutaciones de GraphQL como comandos.

Así que déjame contarte sobre lo que estábamos construyendo. Y nuevamente, gracias a GPT por ayudar con estas diapositivas. Así que 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 resolver o reductor, lo que sea, que almacene algunos eventos en esa base de datos de eventos, que básicamente, cada evento se almacena allí de la manera en que se envía.

Lo enviamos, y luego queremos tener consultas, que básicamente nos permiten 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. Así que lo que podemos hacer, básicamente podemos enviar una mutación de GraphQL, esa mutación puede ir a ese resolver o reductor o lo que sea. Luego almacenar algo dentro de esa base de datos de eventos, ocurrió algún evento. 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. Siempre que un usuario quiera leer algo de mi aplicación, simplemente puede ir y leer eso de esa tabla de caché básicamente. Si elimino esta tabla en la parte inferior, puedo simplemente reproducir todos los eventos y obtener el mismo valor.

Así que el punto extra aquí son las suscripciones porque esto no es una aplicación sincrónica, básicamente el usuario en el front end no sabe cuándo el proceso termina. Lo bueno de GraphQL es que define suscripciones, que básicamente nos permiten enviar un mensaje en tiempo real de vuelta a nuestro front end y decirle al usuario, oye, esto ha terminado. Así que intentemos construir esto con AWS. Haré esto muy rápidamente porque puedes implementar esto con muchas cosas diferentes. Pero déjame guiarte a través de este proceso.

Así que intentemos hacerlo serverless para que esté completamente gestionado, no necesitamos hacer nada por nosotros mismos. Primero, necesitamos alguna capa de GraphQL. Usaremos algo llamado AWS AppSync para eso. AppSync es GraphQL completamente gestionado y escalable por AWS. Te da suscripciones listas para usar. Se integra con muchos servicios diferentes, por lo que puedes simplemente escribir una pequeña pieza de integración llamada Resolver. 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, estados actuales en algún lugar, podemos usar algo llamado DynamoDB, que es una base de datos NoSQL gestionada y escalable por AWS. Es básicamente algo como Mongo, pero ligeramente diferente.

Tiene realmente baja latencia. Pagas solo por las cosas que realmente usas. 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 necesites eso en una etapa temprana, pero es bueno tener esa escalabilidad y puedes transmitir los datos, lo cual es realmente genial porque la base de datos en sí puede decirte cuando los nuevos datos se almacenan allí o los datos cambian.

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

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

Ahora, es difícil usar una función Lambda para muchos eventos. Tenemos muchos, muchos eventos ahora en la aplicación, así 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 Lambda pueden simplemente activarse y responder a eso. Y lo genial de estos servicios es que tiene almacenamiento y reproducción para los eventos, y todo funciona algo así al final. Así que almacenamos los datos. Los datos van debido a 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 enorme, puedes usar una cola delante de todo. Hay una cola de—la famosa cola en AWS llamada SQS, que es escalable nuevamente, y tu uso de papel y cosas así. Así que puedes poner una cola delante de tu base de datos y todo, así que si tienes un enorme pico, no colapsa tu aplicación o algo así. Todas estas cosas escalan, incluso sin una cola, pero en algún punto a una escala enorme, probablemente necesites eso. Así que veamos esto en 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 base de datos, invoca algunas funciones y algunos eventos a algún puente de eventos, bus de eventos, toda la lógica de negocio hace algo, almacena una versión en caché en alguna base de datos y usa otro bus de eventos para notificar al front end o Slack o Microsoft Teams. Y cuando lees los datos, es fácil. Simplemente usas GraphQL o usas REST API para Slack porque Slack no sabe cómo trabajar con GraphQL. Beneficios, obtuvimos una aplicación completamente gestionada. El último evento, donde alguien trabajó después de horas para arreglar el 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 usando servicios para hacer estas cosas y tenemos mejor control y todo es realmente escalable. Desventajas, tenemos muchos servicios nuevos 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. Modelar los datos es realmente difícil con DynamoDB. Afortunadamente, Chaijupiti puede ayudarte con eso. Y lo genial es que puedes usar TypeScript para eventos, esquemas y todo y básicamente redondear todo a una gran solución.

Tuvimos diferentes desafíos con el desarrollo, pruebas, monitoreo, seguridad, pero superamos todos estos. Si quieres saber más sobre estas cosas, siéntete libre de acercarte a mí después de la charla. No tengo suficiente tiempo para hablar de estas cosas ahora. Pero la última cosa genial es que es realmente barato. Así que tenemos 12 entornos que son idénticos y todo cuesta un poco más de $1000 por mes. Y esa aplicación genera mucho más que eso.

Así que en lugar de un resumen, quiero terminar con dos citas. Primero, la cita es que deberíamos darnos cuenta de que algunas reglas simples pueden básicamente volverse mucho más complicadas 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 necesitas comenzar con algo simple. Y otra cosa que realmente cito, que realmente amo es como deberíamos hacer que algo funcione primero. Y luego si tenemos tiempo, lo haremos hermoso. Y finalmente, si realmente, realmente lo necesitamos, 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 solo hazlo hermoso.

Así que eso es todo de mi parte. Esta es la cosa de AI y el cofundador AI que se mencionó al principio. Y esto es básicamente un producto que estoy construyendo que no es AI. Gracias. Eso es todo. Si tienes alguna pregunta.

Muy bien, así que tenemos a alguien que les preguntó, ¿cómo puedes regenerar las tablas de proyección desde la tabla de eventos cuando una lógica de proyección, es decir, el código de Lambda fue actualizado en el medio? Así que básicamente almacenamos cada versión de Lambda porque no pagas por la función Lambda si nadie la está usando. Es realmente barato tener una Lambda para cada versión. Así que si nuestra estructura de eventos cambia, básicamente no solo actualizamos una Lambda en su lugar, creamos una nueva función Lambda y simplemente la conectamos para escuchar una nueva versión del evento. Genial, genial. Esa cosa es realmente fácil porque te da más código, pero eventualmente ya no mantienes las versiones antiguas de cada función Lambda.

Así que, sí. Eso es increíble, eso es increíble. Tenemos otra pregunta que acaba de llegar.

¿Cómo manejas el trazado? Así que el trazado, sí, sí. Necesitas tener algún tipo de como un ID de correlación. Que pase por 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 ir con cosas simples como solo registrar ese ID de correlación y luego usar algo llamado como CloudWatch log insights para simplemente buscar lo mismo a través de las funciones. Eso es increíble. Ahora sé que algunas personas tienen más preguntas, pero puedes venir y encontrarlo.

Él 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 gracias muchas gracias. Definitivamente una de las últimas pero no menos importantes charlas del día, realmente te agradezco.