6
respostas

Push notifications (websocket ou pooling ou varios gets)

Olá Pessoal, tudo bem? Tenho uma aplicação front-end(react) que envia um POST request para uma API(nodejs). Esta API envia uma mensagem para o canal (1) de um servidor rabbitmq específico. Dentro desta mesma API node, existe um worker, que fica subscrito na lista do mesmo canal rabbitmq e quando chega uma nova mensagem, ele faz um tratamento específico para esta mensagem. Após o tratamento, preciso devolver a mensagem ao cliente front-end (react). Algumas das formas que pensei foram: Um service worker no cliente que faz um get a cada x segundos na API pedindo a lista ou apenas o último item, e devolve na forma de push notification. Um service worker no cliente que fica subscrito no rabbitmq e lança a push notification sempre que chegar mensagem nova. (aqui tem o problema da segurança e não sei se existe algum outro problema) Uma conexão do tipo websocket que no final envia ao cliente um push notification. (aqui não saberia exatamente como implementar) Uma conexão do tipo polling?

Qual seria a opção com a melhor escalabilidade/performance? Obrigado!

6 respostas

O seu broker não deveria ficar exposto ao cliente na minha opinião. A mensagem não deveria ultrapassar a fronteira da sua API, expondo detalhes da arquitetura do seu sistema, por várias motivos, segurança, acoplamento, etc; logo não utilizaria a subscrição pelo front-end nesse caso.

Pooling constantes não são muito indicados e poderia ocasionar problemas de performance e prejudicar a escalabilidade do sistema. Acredito que uma boa opção seria implementação de um Webhook/RESTHook, creio que seja o que está procurando.

Oi Rodrigo, gostei do RESTHook e já estou analisando. Websocket (socket.io) seria menos indicado do que o RESTHook, certo?

Creio que dependa do objetivo. O websocket estabelece uma conexão de duas vias entre o cliente e o servidor. Já um webhook a comunicação é de via única.

Para eventos assíncronossos, acredito que webhooks sejam melhores. Não sei a lógica do seu sistema mas dependendo do caso o processamento de uma fila pode demorar, ser agendado, depender da resposta de outro serviço, isso pode levar minutos, horas ou dias. Uma conexão constantemente aberta nesse caso não seria interessante creio eu

É, a principio apenas para notificar quando chegar novas mensagens. Realmente seria prejudicial manter uma conexão aberta.

Estou com dificuldade para encontrar exemplos de uso com React e NodeJs do RESTHook, se você souber de algum exemplo, será de grande ajuda.

Muito obrigado!

Na verdade procurando aqui e relembrando os conceitos lendo denovo, webhooks servem para comunicações server-to-server, onde um dos servidores faz o papel de cliente. Acho que no frontend uma opção seria websocket mesmo.

Também cheguei em uma conclusão parecida. Acabei voltando a tentar fazer com socket mesmo, obrigado de qualquer forma!