5 ms·
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, y
by 1qaz2wsx3edc 14y ago
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 http://rails-bestpractices.com/posts/695-use-after_commit . Just let that data flow, brawhlings.
- drivebyacct2 14y agoWhy 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).
- damncabbage 14y agoEspecially 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.com's page title is "HTML5 WebSocket Powered Realtime Messaging Service", no less.
- 1qaz2wsx3edc 14y agoLet 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.
- drivebyacct2 14y agoHm, I guess I'm blessed with a library for it, but I'm using my own WebSocket server with no sweat right now.
- dylanvee 14y agoActually, 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.