3 ms·

Really interesting article. But it the final line seems slightly disingenuous Building a realtime web application does not require you to begin with a realtime

Really interesting article. But it the final line seems slightly disingenuous Building a realtime web application does not require you to begin with a realtime framework. 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.

kellysutton 14y ago
Very true. I see some folks assume that to get that realtime performance, you need to start with a "realtime" framework. 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.
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 ago
  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).
  - damncabbage 14y ago
    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.com's page title is "HTML5 WebSocket Powered Realtime Messaging Service", no less.
  - 1qaz2wsx3edc 14y ago
    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.
    - drivebyacct2 14y ago
      Hm, 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 ago
    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.

kellysutton 14y ago

Very true. I see some folks assume that to get that realtime performance, you need to start with a "realtime" framework. 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.

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 ago
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).
- damncabbage 14y ago
  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.com's page title is "HTML5 WebSocket Powered Realtime Messaging Service", no less.
- 1qaz2wsx3edc 14y ago
  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.
  - drivebyacct2 14y ago
    Hm, 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 ago
  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.