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

Why we moved from NodeJS to Ruby on Rails

blog.targeterapp.com

Post reply on HN
Print view View original

21–30 of 166 posts

Re: Why we moved from NodeJS to Ruby on Rails

#21

Post by Fluxx »

EternalFury wrote: post #10

Does anyone know 1 major consumer-facing site that was able to scale with Rails? I know Twitter kind of had to move away from Rails due to scalability issues. GameBattles.com also had to back away from Rails after their uptime dropped to 80%. I am not trying to tarnish Rails, I am just curious to learn about some success stories involving Rails at very large scale.

Hulu, Living Social, All of 37 Signals, Groupon, AirBnb, Scribd, Zendesk, Soundcloud, etc.

Twitter's scale is unlike nearly every single web app online, so I think the real story with Rails and Twitter isn't that "they had to move away from it for scalability reasons," but rather it's amazing that they were table to leverage Rails for as long as they did."

Also, Twitter is more dropping Ruby all together rather than just Rails specifically. Again, this isn't to say that Ruby isn't a great language that works for most people (it let Twitter grow quickly to where they are today), but at their scale with their demands it doesn't work well.

Re: Why we moved from NodeJS to Ruby on Rails

#22

Post by secoif »

EternalFury wrote: post #10

Does anyone know 1 major consumer-facing site that was able to scale with Rails? I know Twitter kind of had to move away from Rails due to scalability issues. GameBattles.com also had to back away from Rails after their uptime dropped to 80%. I am not trying to tarnish Rails, I am just curious to learn about some success stories involving Rails at very large scale.

AFAIK Twitter still uses Rails for at least part of their app, perhaps just not for directly serving consumer requests

Re: Why we moved from NodeJS to Ruby on Rails

#23

Post by cmelbye »

heroic wrote: post #15
julian37 wrote: post #11

The data is being written to the db, or being crunched, while the request is ending, and the browser can continue with the important stuff. It sounds like a good fit for NodeJS for sure, but for what it's worth, even in a synchronous web framework nothing forces you to keep the connection open until the request has been processed. I don't know off-hand how to do it in Rails, but say in Java Servlet-based frameworks y…

The point is that the rack middleware would be called for everything, which is very heavy for something so trivial

Of course, it's trivial to write request methods that bypass the rack middleware in Rails.

Re: Why we moved from NodeJS to Ruby on Rails

#24

Post by tptacek »

EternalFury wrote: post #10

Does anyone know 1 major consumer-facing site that was able to scale with Rails? I know Twitter kind of had to move away from Rails due to scalability issues. GameBattles.com also had to back away from Rails after their uptime dropped to 80%. I am not trying to tarnish Rails, I am just curious to learn about some success stories involving Rails at very large scale.

Github, Airbnb, Groupon.

Three reasons people think Rails doesn't "scale":

(1) Earlier versions were adopted by applications with anomalous scaling requirements. So, the project had to "learn to scale" on its feet in a very short amount of time. There were predictable hiccups. Or, put even more simply: it's a young framework that got adopted quicker than people expected.

(2) There's an expectation that web platforms can accomodate near-automatic horizontal scaling with maybe just a couple config-file tweaks. That expectation is unrealistic on any platform for which you can easily hire developers. The reality is that scaling to Twitter or even Github's volume is extremely difficult, and the developers who can reliably accomplish it on any platform are extremely hard to find and extremely expensive.

(3) Rails attracts a kind of junior/casual developer that Python just doesn't have, and (weirdly enough) also I think attracts systems developers like myself that aren't steeped in web scaling folklore, which long story short means lots of projects start out by making lots of embarrassing mistakes.

In our practice we see much more Rails today than we do any other framework (there may be some selection bias there, but probably not too much) and for the most part Rails just works. It is definitely not the case that we see lots of startups go out the gate on Rails, go "oh shit we can't scale", and switch to something else.

Re: Why we moved from NodeJS to Ruby on Rails

#26

Post by randomdata »

EternalFury wrote: post #10

Does anyone know 1 major consumer-facing site that was able to scale with Rails? I know Twitter kind of had to move away from Rails due to scalability issues. GameBattles.com also had to back away from Rails after their uptime dropped to 80%. I am not trying to tarnish Rails, I am just curious to learn about some success stories involving Rails at very large scale.

I know Twitter kind of had to move away from Rails due to scalability issues.

Is that true? I know they replaced their Ruby Starling system with a Scala-based solution, but that wasn't Rails to begin with. They also built a new search engine that didn't use Rails. But as much as I can ascertain, the core consumer facing product still does use Rails today.

Re: Why we moved from NodeJS to Ruby on Rails

#27

Post by no-espam »

FooBarWidget wrote: post #5
mcantelon wrote: post #2

I wonder what testing functionality, specifically, they see missing in the Node ecosystem...

I'm writing a server in Node and to date I'm still trying to figure out how to control the main loop from Node. I want to write tests like this: 1. register some timers and create some sockets 2. send some stuff over the sockets 3. wait until the socket handlers received some data which cause the handlers to unregister the sockets and timers 4. at this point, the main event loop has ended. go to next test and setup a…

#3 I'm not undestanding. Are you doing async? I don't know the socket API but it should be something like this:

it("should wait for socket", function(done) { socket.write("asdfadf", function(err, response) { assert.ok(response.indexOf('token') >= ); done() ); });

#4 If you need a new event loop then write the tests in another module, then simply run your test utility. `mocha` will run all tests in test/*test.js.

RSpec is DOG SLOW! I can run 100s of test in a couple of seconds. Can RSpec even startup in that time?

Re: Why we moved from NodeJS to Ruby on Rails

#28

Post by karterk »

Fluxx wrote: post #25

> NodeJS is suitable for apps that do plenty of short lived requests. I'm confused. Isn't Node's event-loop style programming ideal for long-lived requests? I.e. ones that, under a synchronous i/o, block other requests?

The OP probably meant short-lived with reference to CPU bound requests.

Re: Why we moved from NodeJS to Ruby on Rails

#29

Post by jim-greer »

EternalFury wrote: post #10

Does anyone know 1 major consumer-facing site that was able to scale with Rails? I know Twitter kind of had to move away from Rails due to scalability issues. GameBattles.com also had to back away from Rails after their uptime dropped to 80%. I am not trying to tarnish Rails, I am just curious to learn about some success stories involving Rails at very large scale.

We're using Rails very happily at Kongregate (with MySQL, memcached, and Redis).

Re: Why we moved from NodeJS to Ruby on Rails

#30

Post by julian37 »

heroic wrote: post #15
julian37 wrote: post #11

The data is being written to the db, or being crunched, while the request is ending, and the browser can continue with the important stuff. It sounds like a good fit for NodeJS for sure, but for what it's worth, even in a synchronous web framework nothing forces you to keep the connection open until the request has been processed. I don't know off-hand how to do it in Rails, but say in Java Servlet-based frameworks y…

The point is that the rack middleware would be called for everything, which is very heavy for something so trivial

I didn't mean to imply that NodeJS isn't the best fit for the problem at hand. I was just trying to clarify that it doesn't take an asynchronous framework like Node to keep processing a request after the connection is closed.
Post reply on HN