Why Rails 4 Live Streaming is a Big Deal • Hacker News Board

Re: Why Rails 4 Live Streaming is a Big Deal

#41

Post by bascule » Fri, Aug 03, 2012, 5:04 PM UTC

cageface wrote: post #9

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 think the problem is that Rails was designed to solve the web problems of 2005 and a lot has changed since then. The shift to single-page, JS-driven applications and large numbers of dynamic updates requires a different set of design priorities and the performance characteristics of Ruby itself are more problematic in this environment. In many cases it makes more sense to use something like Go or Node or Erlang tha…

None of this is true. Single-page apps need great JSON APIs. Rails is awesome at making great JSON APIs. With Ember Data on the front end and ActiveModel::Serializers on the backend, you can completely free yourself from writing JSON serialization code.

For websockets-based applications, check out Cramp. And note that as both Rails and Cramp are Rack-based, you can combine them.

"Go or Node or Erlang"

One of these things is not like the others...

Re: Why Rails 4 Live Streaming is a Big Deal

#42

Post by malandrew » Fri, Aug 03, 2012, 5:06 PM UTC

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…

This is exactly what I thought when I saw this on the front page. I'm wouldn't be surprised if they eventually add a kitchen sink library.

Choosing a monolithic framework doesn't encourage separation of concerns and clean interfaces. It also makes scaling horizontally more difficult.

So many ruby gems are built around rails instead of being built as separate discrete libraries. This means that once Rails get really long in the tooth (it has already started to) that it's going to take a bunch of libraries that could have been timeless along with it had they not been so deeply integrated with Rails' architectural features.

The fact that a document like this exists... https://github.com/radar/guides/blob/master/sprockets/sprock...

    This is a detailed guide to the internal workings of Sprockets. Hopefully 
    with this information, somebody else besides Josh Peek, Sam Stephenson, 
    Yehuda Katz and (partially) myself can begin to understand how Sprockets works.

... that connects so many parts of rails isn't a good sign.

node.js, or more specifically npm, got things really right by making the inclusion of libraries really trivial and easy to separate concerns.

I can't begin to imagine the complications with trying to do proper async around a framework that wasn't designed from the ground up to be async. I'd expect that you'll often have to dig into the internals of Rails to discover where something is functioning synchronously where you didn't expect it to. Don't get me wrong, I love the opportunity to dig into other people's code that I rely on, but that is only fun with libraries, not frameworks. When digging around in frameworks you often spend tons of time having to investigate glue code between parts to even understand the part you need to understand.

Re: Why Rails 4 Live Streaming is a Big Deal

#43

Post by malandrew » Fri, Aug 03, 2012, 5:13 PM UTC

bascule wrote: post #41

cageface wrote: post #9

Earlier quoted context omitted.

I think the problem is that Rails was designed to solve the web problems of 2005 and a lot has changed since then. The shift to single-page, JS-driven applications and large numbers of dynamic updates requires a different set of design priorities and the performance characteristics of Ruby itself are more problematic in this environment. In many cases it makes more sense to use something like Go or Node or Erlang tha…

None of this is true. Single-page apps need great JSON APIs. Rails is awesome at making great JSON APIs. With Ember Data on the front end and ActiveModel::Serializers on the backend, you can completely free yourself from writing JSON serialization code. For websockets-based applications, check out Cramp. And note that as both Rails and Cramp are Rack-based, you can combine them. "Go or Node or Erlang" One of these th…

Rails works just fine for REST, but you've forgotten the other side of this and that is the part of the framework that handles the javascript assets, i.e. Sprockets.

The difference between handling the single page app in Rails and node.js is night and day. Sprockets is a nightmare to deal with.

Re: Why Rails 4 Live Streaming is a Big Deal

#44

Post by sunkencity » Fri, Aug 03, 2012, 5:16 PM UTC

sjtgraham wrote: post #15

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…

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 v…

One thing that keeps me from considering Eventmachine mature is that the built in http clients are very crude and undocumented. Example: to get working error handling one needs to use an external http client library like igrigoriks em-http-request instead of the defaults. In this regard Node comes out ahead with better core utilities to boot. Stuff like that is very confusing for new users and puts the whole framework into question (shipping with a http client that is not suitable for production use).

Re: Why Rails 4 Live Streaming is a Big Deal

#45

Post by malandrew » Fri, Aug 03, 2012, 5:20 PM UTC

batista wrote: post #28

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 a…

If you approach it with a Rails/framework mindset, it's worse in node.js, but if you approach designing a large realtime system as many separate loosely coupled node.js processes, it's easier.

Whenever I see someone trying to cobble together their own framework by prepackaging a bunch of node.js libraries I see someone who is doing it wrong.

You shoot yourself in the foot in node.js when you treat it like rails. You shoot yourself in the foot with rails when you try to do anything outside the scope of problems for which it was designed.

Re: Why Rails 4 Live Streaming is a Big Deal

#46

Post by jherdman » Fri, Aug 03, 2012, 5:23 PM UTC

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.

Yup! You're right. My bad.

Re: Why Rails 4 Live Streaming is a Big Deal

#47

Post by bascule » Fri, Aug 03, 2012, 5:24 PM UTC

malandrew wrote: post #43

bascule wrote: post #41

Earlier quoted context omitted.

None of this is true. Single-page apps need great JSON APIs. Rails is awesome at making great JSON APIs. With Ember Data on the front end and ActiveModel::Serializers on the backend, you can completely free yourself from writing JSON serialization code. For websockets-based applications, check out Cramp. And note that as both Rails and Cramp are Rack-based, you can combine them. "Go or Node or Erlang" One of these th…

Rails works just fine for REST, but you've forgotten the other side of this and that is the part of the framework that handles the javascript assets, i.e. Sprockets. The difference between handling the single page app in Rails and node.js is night and day. Sprockets is a nightmare to deal with.

Nobody's forcing you to use Sprockets. You can use e.g. rake-pipeline instead

Re: Why Rails 4 Live Streaming is a Big Deal

#48

Post by PetrolMan » Fri, Aug 03, 2012, 5:29 PM UTC

malandrew wrote: post #43

bascule wrote: post #41

Earlier quoted context omitted.

None of this is true. Single-page apps need great JSON APIs. Rails is awesome at making great JSON APIs. With Ember Data on the front end and ActiveModel::Serializers on the backend, you can completely free yourself from writing JSON serialization code. For websockets-based applications, check out Cramp. And note that as both Rails and Cramp are Rack-based, you can combine them. "Go or Node or Erlang" One of these th…

Rails works just fine for REST, but you've forgotten the other side of this and that is the part of the framework that handles the javascript assets, i.e. Sprockets. The difference between handling the single page app in Rails and node.js is night and day. Sprockets is a nightmare to deal with.

Please explain.

I've actually had a pretty good time dealing with Sprockets. There are the occasional deployment issues but the benefits tend to more than make up for any frustrations.

Re: Why Rails 4 Live Streaming is a Big Deal

#49

Post by bascule » Fri, Aug 03, 2012, 5:30 PM UTC

PetrolMan wrote: post #48

malandrew wrote: post #43

Earlier quoted context omitted.

Rails works just fine for REST, but you've forgotten the other side of this and that is the part of the framework that handles the javascript assets, i.e. Sprockets. The difference between handling the single page app in Rails and node.js is night and day. Sprockets is a nightmare to deal with.

Please explain. I've actually had a pretty good time dealing with Sprockets. There are the occasional deployment issues but the benefits tend to more than make up for any frustrations.

It's pretty slow, among other things

Re: Why Rails 4 Live Streaming is a Big Deal

#50

Post by malandrew » Fri, Aug 03, 2012, 5:31 PM UTC

bascule wrote: post #30

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 fl…

If you have the slow consumer problem then you start forking node.js into separate worker processes (via binary or counting semaphores) and do IPC via something like dnode (locally or even over something like seaport).