Why We Moved From Node Js To Ror

Why we moved from NodeJS to RoR

Disclaimer: This post is in no way a rant about NodeJS or Ruby on Rails. It merely reflects on our decision and the reasoning behind it. Both the frameworks are great for the purpose they are built, and yes that is why a part of our stack is still running on NodeJS.

I am huge fan of NodeJs and I believe it’s a very exciting technology and we will see it getting more popular down the line. I greatly admire it but in spite of everything I recently ported Targeter App from NodeJS to Ruby on Rails.

The reason we wrote it in NodeJS initially, was pretty simple. I had a library that I could use to instantly ship the app (we had 54 hours to make it at Startup Weekend), and I have been coding in JavaScript quite regularly as compared to Ruby. Since our stack involved MongoDB, it only made sense to live in a JS only environment. However, as the app grew, I realized that NodeJS was a wrong choice for the app. Let me outline the reasons below.

NodeJS is suitable for apps that do plenty of short lived requests. It will work fine for a traditional CRUD app, but its not the ideal tool for it. PHP, Ruby, Python have frameworks that are well polished and mature for these apps. NodeJS’ async everything wont have any affect on a CRUD app. Popular frameworks, provide very good caching and everything that is needed for your app to work fine even synchronously.

NodeJS is a very young framework, and packages around it are very immature. I say this with no offence to any of the awesome contributors who have made so many great packages. However, most of the packages are still maturing, and the rapid development of NodeJS means a lot of changes in each new version; and when you use a cutting edge technology, you really should update to the latest version, ASAP. This makes for a lot of trouble for a startup.

Another reason was testing. The testing frameworks in NodeJS are good, but they are no match for what is available on platforms like Django, and RoR. For an app that sees tens of commits a day and all of them have to go live in a day or two, it is important to ensure that nothing breaks, or you will lose the early adopters you worked so hard to get. No one wants to spend a day while you fix trivial bugs.

Finally, we needed something that could cache everything and gets the work done ASAP. Even when our app grows and has thousands of hits per second, we are never going to experience a flood of requests; it is not a chat app! At best the main app will see a 1000 RPS, something that is a piece of cake with RoR and Nginx.

Now, if you are reading still, and you did “read” all this stuff, you pretty much are dying to ask where are we using NodeJS. Well, our app consists of 2 parts. The first is the interface the user sees, and the second that manages the reports, and the logging stuff. The latter is a perfect scenario for using NodeJS; a lot of short lived requests. This part of our app, ends the responses as early as possible, even if we are still pushing things around. This is important because while the request is open, the browsers are waiting for it to complete, damaging the user’s experience. NodeJS’ async everything saves us. 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.

The project we are working on is Targeter App and you can follow updates about our app on twitter or by signing up for our newsletter on Targeter App.

PS: Here is a great guide on where to use NodeJS and how to convince your boss to use it, http://nodeguide.com/convincing_the_boss.html .

See Also: