Live data from Hacker News

Why Rails 4 Live Streaming is a Big Deal

blog.phusion.nl

11–20 of 60 posts

Re: Why Rails 4 Live Streaming is a Big Deal

#11
post #3

Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking…

I'm actually quite excited about this, because I think it makes a lot of sense for this to be in Rails, for a couple of reasons.

First of all, there aren't really any decent solutions for the problem in Ruby. There's a few projects with great potential, but nothing really mature - when I needed to do this, I went with cramp.in, which hasn't been updated in over 6 months now sadly. Node.js would unequivocally have been the better tool for the job, but I didn't want to learn Javascript or Node for this one-off.

Secondly, even if there were mature Ruby equivalents to Node.js, or no impediment to me using Node, I can still see a lot of benefit to doing this in Rails. Personally I think it makes sense to be able to send events down to the clients and hook into the same models and business code you already have in place in the Rails app. (For certain use-cases, for example a project that's in Rails, is mostly a "regular" web app, but you want to give live updates for certain model changes, such as messages, ticket changes, new blog posts, whatever - obviously if the app is totally oriented around live functionality then node would probably be a smarter choice)

(I apologise for using the term "Node.js" as if its another web framework, I know that's not entirely accurate but I don't know enough about it to write more accurately!)

Re: Why Rails 4 Live Streaming is a Big Deal

#12
post #8
post #6

Pardon the ignorance, but can't this be achieved by simple Ajax requests provided by any of the js frameworks? How is this better?

Ajax requires long polling, this PUSHES the response to the server, thus obviating the need for long polling.

> this PUSHES the response to the server

Erm... it pushes the response to the client, not the server, and only pushes after a normal HTTP request.

And of course, it also ties up a huge amount of server resources (total number of clients = total number of workers, since each client permanently ties up a connection forever). Phusion Passenger's docs recommend 8 workers/GB RAM, hope you expect users.

Re: Why Rails 4 Live Streaming is a Big Deal

#13
post #11
post #3

Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking…

I'm actually quite excited about this, because I think it makes a lot of sense for this to be in Rails, for a couple of reasons. First of all, there aren't really any decent solutions for the problem in Ruby. There's a few projects with great potential, but nothing really mature - when I needed to do this, I went with cramp.in, which hasn't been updated in over 6 months now sadly. Node.js would unequivocally have bee…

> First of all, there aren't really any decent solutions for the problem in Ruby.

Uh? Rack has supported streaming since the beginning, and Sinatra has had special support on top of that since 1.3.

> Secondly, even if there were mature Ruby equivalents to Node.js

http://rubyeventmachine.com/

> I can still see a lot of benefit to doing this in Rails.

Don't dismiss the drawbacks. Such as self-DOS-ing. Your Rails application can only have as many clients total as you have workers if they all keep a permanent connection.

Re: Why Rails 4 Live Streaming is a Big Deal

#14
post #11

Earlier quoted context omitted.

I'm actually quite excited about this, because I think it makes a lot of sense for this to be in Rails, for a couple of reasons. First of all, there aren't really any decent solutions for the problem in Ruby. There's a few projects with great potential, but nothing really mature - when I needed to do this, I went with cramp.in, which hasn't been updated in over 6 months now sadly. Node.js would unequivocally have bee…

> First of all, there aren't really any decent solutions for the problem in Ruby. Uh? Rack has supported streaming since the beginning, and Sinatra has had special support on top of that since 1.3. > Secondly, even if there were mature Ruby equivalents to Node.js http://rubyeventmachine.com/ > I can still see a lot of benefit to doing this in Rails. Don't dismiss the drawbacks. Such as self-DOS-ing. Your Rails applic…

"Why your web framework should not adopt Rack API" by José Valim

http://blog.plataformatec.com.br/2012/06/why-your-web-framew...

"This blog post is an attempt to detail the limitations in the Rack/CGI-based APIs that the Rails Core Team has found while working with the streaming feature that shipped with Rails 3.1 and why we need better abstractions in the long term."

Re: Why Rails 4 Live Streaming is a Big Deal

#15
post #3

Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking…

Actually not everything in Node is non-blocking. IO is largely non-blocking by but there is also blocking IO in Node too (synchronous file system functions). Not to mention you definitely will block by doing something computationally intensive in a single tick of the reactor loop.

Have you ever written a non-trivial "real time" app in Ruby? I have (https://github.com/stevegraham/slanger). I think Ruby is actually very well suited to event driven apps. Eventmachine is a very mature library providing asynchronous I/O based on the same pattern as Node. Ruby also has fibers as a native language feature, allowing you to write asynchronous code that looks synchronous, i.e. no nested callback hell, and consequently this makes it a lot easier to write tests for.

Comparing Node to Rails is also absolute nonsense. Rails is a web framework and Node is much lower level than that. Rails is essentially a suite of DSLs for building web applications. Of course there are costs associated with that amount of abstraction.

Re: Why Rails 4 Live Streaming is a Big Deal

#17
post #14

Earlier quoted context omitted.

> First of all, there aren't really any decent solutions for the problem in Ruby. Uh? Rack has supported streaming since the beginning, and Sinatra has had special support on top of that since 1.3. > Secondly, even if there were mature Ruby equivalents to Node.js http://rubyeventmachine.com/ > I can still see a lot of benefit to doing this in Rails. Don't dismiss the drawbacks. Such as self-DOS-ing. Your Rails applic…

"Why your web framework should not adopt Rack API" by José Valim http://blog.plataformatec.com.br/2012/06/why-your-web-framew... "This blog post is an attempt to detail the limitations in the Rack/CGI-based APIs that the Rails Core Team has found while working with the streaming feature that shipped with Rails 3.1 and why we need better abstractions in the long term."

Broken middlewares won't be any less broken now that before.

Re: Why Rails 4 Live Streaming is a Big Deal

#18
post #3

Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking…

> Rails is turning into a framework that includes everything

It's really not turning into anything, Rails had response streaming back in the days, the whole stack has response streaming (as long as the underlying server handles it and there's no broken middleware anywhere) and most microframeworks have response streaming.

There's nothing special to response streaming.

> since everything in node.js is non-blocking.

Not in your wildest dreams, IO is non-blocking and that's about it. Try a bit computation in a node response flow and see your concurrency disappear. If you're looking for "everything is non-blocking", Node most definitely isn't going to cut it.

> There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby

Just as there are in Node. And Ruby has eventmachine which works rather well.

Re: Why Rails 4 Live Streaming is a Big Deal

#19

Is this any different than what SignalR provides for ASP.Net Web Applications?

It's got essentially no relation with SignalR. It's equivalent to using `response.OutputStream.Write` in your HttpHandler.

If you're looking for a SignalR equivalent in Ruby, you need EventMachine.

Re: Why Rails 4 Live Streaming is a Big Deal

#20
post #7
post #3

Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking…

I think this is a bit of an overreaction given that Rails has always been a "batteries included" framework. The fact that Rails allows for socket-like behaviour now is not a tipping point, but simply a nice little feature that may prove useful to some. When Rails starts including a messaging stack, job server, and more, then I'd be right behind you in your complaint.

> When Rails starts including a messaging stack, job server, and more, then I'd be right behind you in your complaint.

Actually, Rails 4 does include a job queue:

https://github.com/rails/rails/commit/adff4a706a5d7ad18ef053...

However, I'm not complaining. ;)

Post reply on HN