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 从我阅读 README 和此线程中获得的信息来看，message_bus 似乎是一个纯粹的通知系统（类似于 Pusher 的替代品）。
我说得对吗，它不是为在分布式系统中实现事件溯源而设计的？
这里所有的例子都与短期消息同步有关，但由于截断机制，无法从事件流中恢复旧的应用程序状态。我有什么遗漏的吗？
技术上你可以提高保留率并使用 PG 作为后端。也就是说，永远保存事务日志是有成本的。从 10 年的交易中重建数据库，虽然可行，但可能不是你会做的事情。