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의 대안)인 것 같습니다.
분산 시스템에서 이벤트 소싱을 구현하도록 설계되지 않았다고 이해해도 맞을까요?
여기 있는 모든 예제는 단기적인 메시지 캐치업과 관련이 있지만, truncation 메커니즘 때문에 이벤트 스트림에서 이전 앱 상태를 복원하는 것은 불가능합니다. 제가 놓친 부분이 있을까요?
기술적으로는 리텐션(retention) 기간을 늘리고 PG를 백엔드로 사용할 수 있습니다. 다만, 트랜잭션 로그를 영원히 유지하는 데는 분명히 비용이 듭니다. 10년 치 트랜잭션으로 DB를 재구성하는 것은 실현 가능할 수 있지만, 실제로 그렇게 하지는 않을 것입니다.