How discourse stays online (Message Bus, Faye, Long Polling)

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

6 Likes

@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?

1 Like

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.

1 Like

That’s great to know. Thank you. Will read up on rack hijack.

1 Like

@sam From what I got by reading the README and this thread, message_bus seems to be a pure notification system (sth like a Pusher alternative)

Am I correct by saying, it’s not designed for implementing event sourcing in a distributed systems?

All examples here are rather related to short-term messaging catch-up, but it’s not possible to restore old app state from the events stream, due to the truncation mechanism. Is there anything I missed?

2 Likes

Technically you could kick retention up and use PG as a backend. That said holding a transaction log forever certainly has costs. Rebuilding a DB from 10 years of transactions, though feasible is probably not something you would be doing.

3 Likes