1. GraphQL Subscriptions with Kafka and Debezium
Bienvenidos a mi charla relámpago sobre suscripciones de GraphQL con Kafka y Debezium. Tenemos tres clientes y un servicio que proporciona una API de GraphQL. Cuando el cliente uno agrega un nuevo cliente, el servicio puede enviar eventos a los clientes dos y tres. Sin embargo, puede haber problemas cuando hay múltiples instancias del servicio o al escribir datos en una base de datos. Para resolver estos problemas, podemos agregar un mensaje broker como Apache Kafka y una herramienta de captura de datos de cambio como Debezium a nuestra implementación.
Hola y bienvenidos a mi charla relámpago sobre suscripciones de GraphQL con Kafka y Debezium. Mi nombre es Nils y soy un desarrollador de software freelance de Hamburgo, Alemania.
Echemos un vistazo a esta imagen aquí. Tenemos tres clientes y tenemos un servicio que proporciona una API de GraphQL. El cliente número dos y el cliente número tres envían suscripciones al servicio para recibir información sobre nuevos clientes. Cuando el cliente número uno envía una mutación para agregar un nuevo cliente, nuestro servicio y nuestra API de GraphQL pueden enviar eventos al cliente número dos y tres informándoles sobre los nuevos clientes.
En la vida real, esta configuración puede ser un poco más compleja porque podríamos tener más de una instancia del mismo servicio como en este caso. En este caso, el cliente número dos envía la solicitud de suscripción a la instancia del servicio número uno, mientras que el cliente número tres envía su solicitud a la instancia del servicio número dos. Ahora, cuando el cliente número uno ejecuta la mutación en la instancia del servicio número uno, la instancia del servicio número uno puede informar al cliente número dos sobre el nuevo cliente. Pero desafortunadamente, el cliente número tres no recibe un evento porque la instancia del servicio número dos no sabe nada sobre el nuevo cliente agregado ni sobre la mutación ejecutada.
Para resolver este problema, la instancia del servicio número uno debe informar a la instancia del servicio número dos sobre las cosas que suceden, como la mutación. Podemos resolver este problema agregando un mensaje broker como Apache Kafka a nuestra implementación. En este caso, el cliente uno todavía envía una mutación a la instancia del servicio número uno. Pero en lugar de enviar la suscripción directamente al cliente dos, la instancia del servicio uno envía un mensaje al mensaje broker. El mensaje contiene la información sobre el nuevo cliente y tanto la instancia del servicio uno como la dos están escuchando este mensaje del mensaje broker. Cuando reciben el mensaje, pueden enviar los datos de la suscripción a ambos de sus clientes conectados, el dos y el tres. Ambos clientes están contentos ahora.
En la vida real, las cosas son un poco más complejas porque estamos escribiendo data en una base de datos. En este caso, la instancia del servicio uno y dos deberían escribir en la misma base de datos, y cuando la instancia del servicio uno escribe algo en la base de datos, el mensaje aún se enviará a Apache Kafka y los clientes dos y tres serán informados sobre el nuevo cliente. Pero en la vida real, las cosas pueden salir mal. Por ejemplo, después de confirmar el nuevo cliente, la instancia del servicio número uno no puede enviar un mensaje a Kafka por cualquier motivo. En ese caso, ninguno de los clientes recibirá un evento. Además, lo que puede suceder es que tengamos otra aplicación que escriba directamente en la base de datos para que la instancia del servicio número uno no sepa acerca de estos cambios y, por lo tanto, no pueda enviar un mensaje a través del mensaje broker. Y nuevamente, los clientes dos y tres no son informados sobre el cambio en nuestros datos.
Para resolver este tipo de problemas, podemos agregar una herramienta de captura de datos de cambio como Debezium a nuestra pila de herramientas. Una herramienta de captura de datos de cambio lee todo lo que sucede en su base de datos como inserciones, actualizaciones y eliminaciones, y escribe eventos para estas acciones en un mensaje broker. En el caso de Debezium, Debezium publica eventos de cambio en Apache Kafka. Un evento de cambio de Debezium podría verse así. Tiene un atributo de origen donde se establece la tabla, por ejemplo. Tiene una operación como actualización, eliminación o inserción que describe lo que ha sucedido en la base de datos, y tiene los datos antes y después.
2. Arquitectura con Debezium y Kafka
En este caso, Debezium recoge los cambios directamente de la base de datos y envía mensajes de eventos CDC al mensaje broker conectado. Las instancias del servicio reciben estos eventos, los interpretan y envían datos de suscripción a los clientes. Gracias a Debezium y Apache Kafka, podemos estar seguros de que cualquier cambio en la base de datos se publicará en Kafka y será recibido por nuestra instancia del servicio. También podemos utilizar esta combinación de tecnologías para consultas mediante la creación de una base de datos de modelo de lectura dedicada para nuestra API de GraphQL.
En este caso, los datos antes y después de una operación de actualización. Nuestra arquitectura con Debezium se vería así. El cliente uno todavía envía la mutación directamente a la instancia del servicio uno. La instancia del servicio número uno escribe el nuevo cliente en la base de datos o alguna otra aplicación escribe algo en la base de datos.
Y en ambos casos, Debezium recoge los cambios directamente de tu base de datos y envía un mensaje de evento CDC al mensaje broker conectado. Tanto la instancia del servicio número uno como la número dos reciben estos eventos de captura de cambios CDC, pueden interpretar estos eventos y enviar datos de suscripción a través de su API de GraphQL al cliente número dos y al cliente número tres. Y ambos clientes están contentos ahora.
Gracias a las garantías de entrega que Debezium y Apache Kafka nos brindan, podemos estar seguros de que cualquier cambio en la base de datos, ya sea una actualización, inserción o eliminación, se publicará en Kafka y será recibido por nuestra instancia del servicio, de modo que podemos estar seguros de que podemos enviar una suscripción para cualquier cambio en la base de datos por cualquier motivo que haya cambiado la base de datos.
Si quieres probar esto por ti mismo, he creado una pequeña aplicación de muestra construida con GraphQL Java y Spring para GraphQL. Puedes encontrar el código fuente en el repositorio de GitHub en la siguiente URL.
Por cierto, esta combinación de tecnologías no solo la podemos utilizar para suscripciones, sino que también creo que la podemos utilizar para consultas. Podríamos construir una base de datos de modelo de lectura dedicada para nuestra API de GraphQL. Imagina que tenemos una lista de microservicios cada uno conectado a su propia base de datos. Utilizando Debezium y Apache Kafka, podemos recoger todos los cambios de todas las bases de datos y construir una base de datos optimizada y dedicada solo para nuestra API de GraphQL. La API de GraphQL puede leer los datos de esta base de datos específica y no necesita consultar todos los microservicios para obtener los datos solicitados en una consulta de GraphQL. Hasta aquí, muchas gracias por hoy, nos vemos y diviértete construyendo APIs de GraphQL.
