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 سنوات من المعاملات، على الرغم من أنها ممكنة، ربما ليست شيئًا ستفعله.