Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rails 4 Live Streaming is a Big Deal

blog.phusion.nl

Post reply on HN
Print view View original

21–30 of 60 posts

Re: Why Rails 4 Live Streaming is a Big Deal

#21

Post by FooBarWidget »

adriand wrote: post #20
jherdman wrote: post #7

Earlier quoted context omitted.

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. ;)

Well to be more accurate: it includes a job queue API with the actual implementation being pluggable. It does not do job queuing by itself. It's just like the cache API, actual implementation depends on the cache store.

Re: Why Rails 4 Live Streaming is a Big Deal

#23

Post by jeltz »

masklinn wrote: post #12
jherdman wrote: post #8

Earlier quoted context omitted.

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.

Streaming works fine with thin + nginx. A single thin instance can handle hundreds (or thousands depending on how much data you stream) of connected users without any problems. The only risk I see here is that long requests can lock up the steaming. Our solution is to have nginx route to one server for streaming and to another for normal requests.

Re: Why Rails 4 Live Streaming is a Big Deal

#24

Post by randomdata »

ZoFreX wrote: post #11
amix wrote: 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.

Even ignoring other frameworks, Rails has supported streaming through various APIs since at least the 2.x days.

In Rails 2, you would pass a Proc to the render method giving direct access to the response.

Rails 3 changed the API to any Enumerable assigned to self.response_body, as described in the article.

Rails 4 gets yet another API. It may be arguably cleaner, but the end functionality remains the same as it has always been.

Re: Why Rails 4 Live Streaming is a Big Deal

#25

Post by batista »

alexyoung wrote: post #5

"Can Rails compete with Node.js?" For the perplexed: Node isn't a web framework.

>For the perplexed: Node isn't a web framework.

For the perplexed: it doesn't matter.

Take it to mean "Node+whatever" vs Rails. Or even "raw Node + totally custom js framework on top" vs Rails.

Re: Why Rails 4 Live Streaming is a Big Deal

#27

Post by chaz »

amix wrote: 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…

Agree that best tool for the job is important, and that node.js may be the right tool if your app is very realtime-focused. But no need to go node.js if all you need is a progress indicator.

I think the modern web stack does need an easy way to do realtime communication, and as a casual Rails engineer since pre 1.0, I'm happy to see this get support out of the box.

Re: Why Rails 4 Live Streaming is a Big Deal

#28

Post by batista »

amix wrote: 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…

>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 libraries).

How is developing "large realtime systems" in Node any better?

It's a thrown together library on top of V8, in a language that doesn't even have concurrency primitives.

Doing non-blocking stuff in Node is like powering your car by pedalling. It works and takes you places, but it misses the point of needing a car in the first place.

Re: Why Rails 4 Live Streaming is a Big Deal

#29

Post by mikeryan »

alexyoung wrote: post #5

"Can Rails compete with Node.js?" For the perplexed: Node isn't a web framework.

It took about 2 weeks of working with Node and you quickly realize where its place is your stack, and its very much not the same thing I use Rails for. It's also a pretty distinct line that is pretty easy to determine.

I also find any Node/Rails comparison's pretty silly honestly, they're very different tools, and though you can do the same thing with each, I wouldn't.

Re: Why Rails 4 Live Streaming is a Big Deal

#30

Post by bascule »

amix wrote: 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…

"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 libraries)."

As opposed to doing I/O flow control in an asynchronous, callback-driven system? Have you ever heard of the "slow consumer problem"?

Not only can you build realtime systems with threads, by using synchronous I/O you'll be taking advantage of all the flow control TCP has to offer, instead of unboundedly filling up write buffers.

Post reply on HN