Yeah, the whole backend is powered by message_bus. The android/ios client long-polls. Not sure if this is the best use of message_bus, but It works w/o the added complexity of web sockets. The major win is that it fits in our existing rails stack. The only disadvantage i’ve come across so far is that I can’t find an elegant way to support the typing indicator.
http://www.eggie5.com/58-real-time-messenging-w-ruby-ios-android
@sam I see this works with Thin. What about Unicorn, I’ve read that Thin is excellent (best supported) with Long-Polling, is this why you only support Thin when using Long-Polling with your message_bus gem?
Please correct me if I’m wrong but looking at the code Long-Polling seems to be enabled if Thin is running?
It works fine with unicorn, in fact we host all our sites on unicorn.
unicorn, passenger and puma all support rack hijack. This means message_bus can pull sockets out of the normal lifecycle and release the connections back to unicorn while keeping the socket open.
That’s great to know. Thank you. Will read up on rack hijack.
@sam Pelo que entendi lendo o README e esta thread, message_bus parece ser um sistema de notificação puro (algo como uma alternativa ao Pusher)
Estou correto ao dizer que ele não foi projetado para implementar event sourcing em sistemas distribuídos?
Todos os exemplos aqui estão mais relacionados à recuperação de mensagens de curto prazo, mas não é possível restaurar o estado antigo do aplicativo a partir do fluxo de eventos, devido ao mecanismo de truncamento. Há algo que eu perdi?
Tecnicamente, você poderia aumentar a retenção e usar o PG como backend. Dito isso, manter um log de transações para sempre certamente tem custos. Reconstruir um banco de dados a partir de 10 anos de transações, embora viável, provavelmente não é algo que você faria.