Rails is used for CRUD operations but Node/Socket.io/Jquery are your 'realtime' framework. Its just simple, proprietary (and not in a bad way) and does exactly the job you need.
We probably will hit a ceiling with Rails (once we decide to take the time to update down from 500ms to 50ms, perhaps) that we might not run into using something built for the job. LayerVault wasn't built to be realtime first and foremost.
No disingenuity intended.
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.
Sure, you can use Sever-Sent-Events, but a Websocket would be sufficient too (and probably works in more places, no less).
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?
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.