No exemplo informado pela professora utilizado para propagar mudanças, o cadastro e GET estão no mesmo serviço, com isso, ao realizar o cadastro de um novo evento, é adicionado no sink para propagar a atualização no client que está conectado .
Porem se imaginar um cenário onde o cadastro não esta na mesma API que realiza o GET , por alguma regra de negócio ou algo do tipo. Como fazer para ser propagada as alterações para o client ?
Olá, Luis! Tudo certo?
Essa é uma dúvida interessante e bastante comum quando se trabalha com arquiteturas distribuídas. Quando o cadastro e o serviço de GET estão em APIs diferentes, você pode utilizar algumas estratégias para propagar as alterações para o cliente.
Uma abordagem comum é usar um sistema de mensageria, como RabbitMQ ou Kafka. Quando um novo evento é cadastrado, a API responsável pelo cadastro pode publicar uma mensagem em um tópico ou fila. A API que realiza o GET pode estar inscrita nesse tópico ou fila e, ao receber a mensagem, pode atualizar seu estado interno ou notificar os clientes conectados.
Outra alternativa é usar um banco de dados reativo ou uma solução de cache que suporte eventos, como o Redis com Streams. Assim, quando o cadastro é feito, um evento é gerado e a outra API pode reagir a esse evento.
Por exemplo, se você usar Kafka, o fluxo seria algo assim:
A API de cadastro publica uma mensagem em um tópico Kafka quando um novo evento é cadastrado.
A API de GET está inscrita nesse tópico e, ao receber a mensagem, pode atualizar os clientes conectados.
Essas soluções ajudam a manter suas APIs desacopladas enquanto ainda permitem a propagação de eventos entre elas.
Espero ter ajudado e bons estudos!