Arquitecturas Avanzadas de GraphQL: Event Sourcing y CQRS sin servidor

Rate this content
Bookmark

GraphQL es una herramienta poderosa y útil, especialmente popular entre los desarrolladores frontend. Puede acelerar significativamente el desarrollo de aplicaciones y mejorar la velocidad de la aplicación, la descubribilidad de la API y la documentación. GraphQL no es solo adecuado para API simples, puede impulsar arquitecturas más avanzadas. La separación entre consultas y mutaciones hace que GraphQL sea perfecto para el event sourcing y Command Query Responsibility Segregation (CQRS). Al hacer que tu aplicación GraphQL avanzada sea sin servidor, obtienes una arquitectura completamente administrada, económica y extremadamente potente.

28 min
02 Jun, 2023

Video Summary and Transcription

GraphQL es un lenguaje de consulta sin versión y de tipo fuertemente tipado que te permite solicitar datos específicos y obtenerlos en formato JSON. Simplifica la recuperación y modificación de datos al permitir que el servidor maneje todas las operaciones necesarias. Las arquitecturas sin servidor, como AWS Lambda, son escalables, rentables y adecuadas para aplicaciones basadas en eventos. El event sourcing y CQRS son técnicas que garantizan la consistencia y separan las partes de lectura y escritura de una aplicación. La construcción de una API GraphQL con comandos y consultas se puede lograr utilizando AWS AppSync y DynamoDB. Este enfoque ofrece baja latencia, escalabilidad y admite múltiples lenguajes. Los desafíos incluyen la complejidad de la aplicación, el modelado de datos y el seguimiento, pero comenzar con simplicidad y hacer que algo funcione primero puede llevar al éxito.

Available in English

1. Introducción a GraphQL y sus beneficios

Short description:

Hoy estoy aquí para contarles algunas historias. La primera historia es sobre GraphQL. Facebook construyó una aplicación móvil empaquetada dentro de una vista web con datos alimentados como HTML. Tenían problemas para servir datos, así que crearon GraphQL. Te permite solicitar datos específicos y obtenerlos en formato JSON. GraphQL es fuertemente tipado, tiene una jerarquía y proporciona documentación. No tiene versiones.

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.

2. Introducción a los conceptos básicos de GraphQL

Short description:

Antes de GraphQL, las aplicaciones funcionaban enviando múltiples solicitudes para obtener diferentes datos. GraphQL te permite decirle al servidor qué datos quieres y el servidor se encargará de todas las operaciones necesarias para recuperar y devolver esos datos. Se utilizan tipos, esquemas y resolvers para definir y recuperar los datos. GraphQL admite consultas, mutaciones y suscripciones para la recuperación de datos, modificación y actualizaciones en tiempo real.

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.

3. Arquitecturas avanzadas de GraphQL y Serverless

Short description:

Hoy hablaremos sobre arquitecturas avanzadas de GraphQL, por ejemplo, serverless event sourcing con CQRS. Permítanme contarles una historia sobre serverless. ¿Quién utiliza serverless en algún momento? Probablemente lo primero que vimos en Internet fue algún artículo en 2012, que decía que el futuro de todas las aplicaciones de software es serverless. Hace casi 10 años, AWS anunció algo llamado AWS Lambda, que te permite escribir una función y adjuntarle un disparador. Serverless se puede aplicar a muchas cosas, no solo a la computación. Escala automáticamente, pagas por solicitud y está completamente administrado por tu proveedor de servicios. Es bueno para aplicaciones impulsadas por eventos, equipos que se mueven rápido y cuando no puedes predecir tu carga de trabajo. Serverless es como una infraestructura administrada donde otra persona está ejecutando tus servidores.

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.

4. Prototipos sin servidor y Event Sourcing

Short description:

Sin servidor es bueno para prototipos. Lo usé para construir una aplicación de PTO. Pero a medida que nuestra aplicación creció, enfrentamos problemas con el almacenamiento y la gestión del estado de la aplicación. Encontramos una solución llamada event sourcing, que es similar a Redux.

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.

5. Event Sourcing and CQRS

Short description:

Redux tiene la misma idea que el event sourcing. El event sourcing asegura que todas las aplicaciones modificadas en todos los eventos se almacenen como una secuencia. CQRS, o Command Query Responsibility Segregation, divide las partes de lectura y escritura de una aplicación. Utiliza objetos diferentes para comandos y estados. CQRS proporciona consistencia eventual y es útil para partes específicas de una aplicación.

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í.

6. Building a GraphQL API with Commands and Queries

Short description:

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 usar las consultas de GraphQL como consultas y las mutaciones de GraphQL como comandos. 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. Lo enviamos y luego queremos tener consultas, que básicamente nos permite leer los datos de la base de datos como un estado, no como una serie de eventos. Así que intentemos construir esto con AWS. Usaremos algo llamado AWS AppSync para eso. AppSync es un GraphQL completamente administrado y escalable por AWS. Te brinda suscripciones listas para usar. 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.

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.

7. Benefits of Low Latency and AWS Lambda

Short description:

Tiene baja latencia y puede manejar millones de solicitudes por segundo. Puede transmitir datos y recibir notificaciones de datos nuevos o modificados. AWS Lambda se puede utilizar para crear proyecciones y es rentable. Admite varios lenguajes.

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.

8. Using AppSync, EventBridge, and SQS Queue

Short description:

Ahora, si volvemos a MyDiagram, podemos usar AppSync para esta parte. Podemos almacenar los datos en DynamoDB. DynamoDB puede notificar a Lambda los cambios y crear proyecciones. Diferentes funciones de Lambda pueden manejar eventos utilizando EventBridge. Las consultas siguen siendo las mismas. Para cargas altas, utiliza una cola SQS. En Vacation Tracker, los datos se almacenan, las funciones y los eventos se invocan y se almacena una versión en caché. El front-end o Slack se notifica utilizando un bus de eventos. Leer los datos es fácil con GraphQL o una API REST para Slack. La aplicación está completamente administrada y estable.

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.

9. Challenges, Quotes, and Conclusion

Short description:

Menos código, mejor control, escalabilidad. Desafíos con nuevos servicios y trazabilidad de eventos. Complejidad de la aplicación y modelado de datos en DynamoDB. Superar desafíos en desarrollo, pruebas, monitoreo y seguridad. Rentabilidad. Comenzar con simplicidad y hacer que algo funcione primero. Hacerlo hermoso conduce a la velocidad. Se menciona un producto de IA. Abierto a preguntas.

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.

10. Handling Projection Table Regeneration and Tracing

Short description:

Almacenamos cada versión de Lambda para manejar las actualizaciones en la lógica de proyección. Crear una nueva función Lambda para cambios en la estructura de eventos es fácil y rentable. La trazabilidad se puede realizar utilizando un ID de correlación y herramientas como X-ray o CloudWatch log insights. El orador está disponible para más preguntas en la sala de preguntas y respuestas.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
React Day Berlin 2022React Day Berlin 2022
29 min
Get rid of your API schemas with tRPC
Do you know we can replace API schemas with a lightweight and type-safe library? With tRPC you can easily replace GraphQL or REST with inferred shapes without schemas or code generation. In this talk we will understand the benefit of tRPC and how apply it in a NextJs application. If you want reduce your project complexity you can't miss this talk.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.