What is Nodejs3 min read

what is nodejs ?

Node.js is a Javascript server

Is node js that simple? Well, Yes & No. Depends on whether you love Javascript or not.

In “not-so-simple” terms, node.js is a high performance, light weight platform which uses an event-driven, non-blocking I/O model, making this a perfect match for data-intensive real-time applications that run across distributed devices.

You : Wooooww…. hold on.. hold on.. what is all this man!?

Me : This is nodejs!

You : Yeah! i get that much.. Can you break this up for me?

Me : Sure.. So here it goes..

Early 2009, Ryan Dahl (this guy) was looking at a file upload progress bar on Flickr and was wondering how the progress bar is updating without a page refresh? This is a file upload via http & not ftp!!. Then he found out that the client was polling the server like every second asking, how much of the file is uploaded? And this kind of seemed very tiresome and boring way of doing things. So Ryan wanted to build a Web server that is optimized for this kind of a behavior, where the server is non-blocking in nature. i.e. I/O needs to be handled differently

You : Ahh!! Nice. Go on..

Me :  Ok, After a lot of experimentation on Ruby, Python, VB & other high level languages, Ryan had found that only Javascript seems very apt for this purpose. Things like closures, anonymous functions are an added advantage with Javascript. And more over this is a dynamic web server, so a web developer will be aware of Javascript (avoiding training  altogether!).

Node.js uses Google’s V8 Javascript engine to parse the Javascript code. Technically speaking Node.js is ~40% Javascript & ~60% C++.

Lets actually get into the nitty gritty’s of Node. So now, we need a high performance server, that does not block on I/O.

You : What up with this I/O man? I don’t understand how I/O operations will reduce the speed & performace .

Me : Okay, take a look at this

So what exactly is the software or your application doing when the db query is going on? Waiting for the response right? Another example

This is another I/O operation, where we wait till the file is read.

On a simple scale


The green part indicates the actual operation that needs to take place for a given task and the orange part is the waiting for the I/O on that task. Now can you see the difference, How I/O will reduces the speed of your application?.

You : Makes sense dude!

Me : Moving along, we can either use multi-threading or multi-processing to achieve this. But is there anything we can do better? The answer is yes. When we compare the I/O operation rate (i.e. concurrency vs requests/sec) between an Apache and Nginx, it will look something like this



As you can see, the Apache’s reqs/sec dropped as more concurrent users are added, where as Nginx looks pretty stable.

The secret behind this success is “Apache uses one thread per connection, where as NGINX uses an event loop.”

So what is an event loop?


It is a simple mechanism – when an event is raised, a task is sent to the server. The main thread stacks up the received event task in a queue. An event loop keeps monitoring the queue picks up the new event task and redirects it to its corresponding I/O operation. And the main thread is free to pick another event task. Once the I/O part of the event task is completed, it is again pushed back to the event queue by the thread pool. Now the event loop checks if there are any more pending things to be done for this task and dispatches the same accordingly.

Neat right? The main thread never waits for completion of any I/O tasks. This keeps our server pretty free & ready to serve more requests.

You : So if this mechanism is that powerful, why aren’t people using this?

Me : That’s a really good question. As per the research done by Ryan, there are 2 major reasons

1. Cultural Bias

2. Missing Infrastructure

Cultural Bias

  • This is how we are taught I/O

  • Code like this is rejected as too complicated.

Missing Infrastructure

  • Single threaded event loops require I/O to be non-blocking and most libraries are not.
  • No closures or anonymous functions in C, making callbacks difficult.
  • Database libraries (e.g. libmysql client) do not provide support for asynchronous queries
  • Asynchronous DNS resolution is not a standard on most systems.

You : Sounds good, but how can we implement this?

Me : So, this where we can leverage the power of Javascript to get things done. Things like Anonymous functions, closures & “Only one callback at a time” are the key.

The DB query which we saw earlier, can be written like this

So, the complete operation is async. You need not wait for the response from the db to move to the next statement.

This is a quick view of the Node.js stack. (May be I’ll write a detail article about this later.)

nodejs standard library  source

You : I am not sure if I can use Node.js for all my projects! Is async always better? When do I actually use node.

Me : There is an amazingly healthy discussion going on SO about the same. You can figure it out yourself.

And most importantly – Avoid CPU intensive tasks, remember there is only 1 thread

Now all this is out of the way, lets see what all can be done with node.js.

Thanks for reading! Do comment.