As soon as the author wrote "socket.io" the gears in my brain ground to a stop.
Use observers, pusher, and a client side MVC. Don't serialize records deeply, your client side controller or framework should handle the updates nicely. IMO use `after_commit` http://rails-bestpractices.com/posts/695-use-after_commit . Just let that data flow, brawhlings.
Why oh why is pusher better than a websocket here? Especially since pusher is a third party service and it's probably using (or is able to use) websockets as a transport for that push anyway?
Sure, you can use Sever-Sent-Events, but a Websocket would be sufficient too (and probably works in more places, no less).
Let me clarify, you can use pusher, or something like firehose.io.
Pusher uses a web socket. Pusher is cheaper when comparing against running our own dumb pub/sub server.
Rails 4 will support SSE, however we're not riding that edge as there were existing solutions to the problem.
-
I think this covers most realtime problems without having to code that much, let alone a secondary server/service to handle the problem, we outsourced it, were happy.
Actually, SSE is a better fit here: it works in many more browsers than WebSockets when you count the existence of SSE polyfills, and you don't need the bidirectionality of WebSockets here.
Use observers, pusher, and a client side MVC. Don't serialize records deeply, your client side controller or framework should handle the updates nicely. IMO use `after_commit` http://rails-bestpractices.com/posts/695-use-after_commit . Just let that data flow, brawhlings.