When to Use Node.Js VS Sinatra VS Rails

When to use node.js vs sinatra vs rails?

If you're building a complete web application, you should probably use Rails as it provides the most comprehensive services. You can also leverage an enormous amount of work produced by the community.

Sinatra is great for producing really thin, no-nonsense application services. You don't get much to work with, but it is very fast. If you need a database connection, you will have to add it in, and things like this can make creating even medium-sized applications a challenge. Basically if you need something very simple and don't need Rails, you probably need Sinatra.

node.js is a great new framework for producing responsive, scalable applications, but it doesn't have nearly the library of add-ons that a mature platform like Rails does. node.js really excels at applications based on streaming and on-demand data transformation. Some of the examples produced in Node Knockout are very interesting, but these were produced by some exceptional teams.

While the Node Knockout entries are very well done, when compared to the sort of applications that were produced in the 2009 Rails Rumble they seem to come across as toys lacking depth and complexity. This is not to discredit the work done by the Node Knockout teams, but it does show that the strengths of node.js are mostly to do with real-time events and less with conventional more ordinary DB-based apps.

Could someone give me an example of node.js application

Sinatra and Rails are both web frameworks. They provide common web development abstractions, such as routing, templating, file serving, etc.

node.js is very different. At it's core, node.js is a combination of V8 and event libraries, along with an event-oriented standard library. node.js is better compared to EventMachine for Ruby.

For example, here's an event-based HTTP server, using EventMachine:

require 'eventmachine'
require 'evma_httpserver'

class MyHttpServer < EM::Connection
  include EM::HttpServer

  def post_init
    super
    no_environment_strings
  end

  def process_http_request
    response = EM::DelegatedHttpResponse.new(self)
    response.status = 200
    response.content_type 'text/plain'
    response.content = 'Hello world'
    response.send_response
  end
end

EM.run{
  EM.start_server '0.0.0.0', 8080, MyHttpServer
}

And here's a node.js example:

var http = require('http');

http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello world');
}).listen(8000);

The benefit of this approach is that the server doesn't block on each request (they can be processed in parallel)!

node.js has its whole standard library built around the concept of events meaning that it's much better suited to any problem that is I/O bound. A good example would be a chat application.

Sinatra and Rails are both very refined, stable and popular web frameworks. node.js has a few web frameworks but none of them are at the quality of either of those at the moment.

Out of the choices, if I needed a more stable web application, I'd go for either Sinatra or Rails. If I needed something more highly scalable and/or diverse, I'd go for node.js

Sinatra vs Node.js performance for a simple REST API

100k requests a day is roughly a request per second assuming a flat distribution of requests during the day. Both solutions will probably serve that without a problem. You're probably falling into the premature optimisation trap.

That being said, Javascript, because of it's asynchronous nature is significantly better at high i/o than Ruby (Sinatra is just a simple web framework, Node is just how you run Javascript on a server).

Now as per the "what should I do", I suspect most people would tell you to use the prototype you already have working and use it until it's no longer good, if it ever comes to it. Seeing it's such a small app it shouldn't be a problem to rewrite it later with Node anyway!

Can node.js replace Ruby?

Express is a framework much like Sinatra based off of Node.js. It can be used to build an entire website, with complex routing and all the jazz. I don't know if this is the best use for Node, but it is possible.

Nodejs/rails/backbone architecture

You certainly can use Node.js or Rails or both with Backbone.js - I have used stacks with all or combinations of these technologies and they are great. Picking which ones to use should depend on what you are building and to a lesser extent, your comfort levels with each technology.

Replacing Rails with Node

Node.js can easily replace the functionality of Rails, i.e. talking to the database, containing model logic, serving pages and assets and controlling routing. There are tons of tons of modules available for this. A common solution is to use Express(a simple Sinatra type web framework) to serve pages and handle templating and an ODM/ORM to handle database objects. There are also more extensive rails-like frameworks such as Geddy.

My take on Node as a direct replacement for Rails

If you simply want the functionality of Rails, use Rails. Ruby/Rails code looks cleaner and is more managable in my opinion and it is a bit more mature (feel free to flame...). If you are serving a lot of different pages, Rails does a good job of organizing things. However, if you are making a single page app, which is one of the main use cases for Backbone, then much of the Rails package is unnecessary - you just need the model logic and database interaction. In this case, something like Express(Node) or Sinatra(Ruby) with an ORM and RESTful routing for communicating between back and front end will sufice.

Added functionality with Node

The more compelling use cases for Node are for sites with real time or multiplayer aspects; Node is great for concurrency and asynchronousity. Use Node if you have clients sending data to each other without reloading pages or data being pushed from server to client without another page load (a great module for doing this is Socket.io). Again, this is a use case that works well with single page or high interaction interfaces that Backbone caters to.

Concurrent information. Sinatra or Node.js?

My suggestion is to go with whatever you are more comfortable developing and deploying on. I'd personally go with Sinatra, but that's because I personally find it fast and elegant to develop with. If speed is critical, and more important than development time, you'll need to develop a reasonable benchmark on both and test it on both.

Clarifications about Rails and Node.js

There aren't enough differences between Node.js and Rails for it to practically matter.

A lot of what Node.js can do can be pulled off in Rails with things like EventMachine and Pusher. So unless you are really familiar with Rails' limitations, and know you'll be pushing the boundaries, you'd be hard pressed to make something a seasoned Rails developer couldn't do.

Having built apps in Node and Express I can say that they alone aren't enough to make a sexy application. They can seem just as old and stale if you don't have an outstanding frontend UI to facilitate the backend possibilities. Instead of comparing backend servers, I think the real future of doing amazing things is in front-end JavaScript frameworks like Backbone.js that use Express/Rails/Node.js on the backend.

I have chosen to go in the direction of Backbone.js with Rails as my backend API server. Because it's so easy to rapidly create a very nice RESTful backend server in Rails. Rails also makes working with CoffeeScript and precompiling/organizing Backbone code a breeze. There are already decent Backbone.js gems out there for Rails.

The Rails core is also able to acknowledge and embrace the fact that frontend JS MVCs are logically a good next step, and they have been working to strengthen the bond between the two. For those same reasons they have also worked to make Rails an even better API server so that it can work with frontend JS easier. Node.js and Express aren't putting as much effort to coordinate with frontend JavaScript MVCs as the Rails community is.

Being good with a JavaScript frontend MVC and Rails as a backend makes you also great for both worlds in terms of getting a job. You will easily be able to hop onto a Node.js project and add value to that team with your superior frontend experience, and you can also roll with the punches on a Ruby on Rails team and add value to them as well.

---

Related Topics