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