The advantage is that Node uses async/non-blocking IO.
For example, say your portal needs to collect info from 3 sources A, B, and C. In a synchronous system, you would have to request service A, wait for a response, then request B, wait, and so on. This means your request is utilizing the system for all that time, unable to serve other requests, without extra threads or processes.
Node, and other async systems, when they call for IO, like a service, a callback is registered for the result. So instead of having to wait for the result, the system becomes available for other actions, like other requests. So in this case you could request service A, B, and C all at once, and while you are waiting for the responses, the system can be handling other requests. When any of those services completes, it calls back to your code so you can handle the results, and give a response to the client.
So the advantage is that instead of a request taking A + B + C + extra time, it can take max(A, B, C) + extra time to serve the request, while serving other requests concurrently.
Node is not the only way to achieve this, many async systems exist like Tornado for python, EventMachine for ruby, and many others. But the JavaScript in node can be particularly fun to work with especially if you are also doing the front-end JavaScript, as it pretty much brings the context-switching in your brain to almost nothing.
Great explanation--the light bulb finally went on for me regarding node.js.
Regarding the other framework event models (esp. EventMachine), is it beneficial or wise to use node for the I/O intensive stuff and another framework (e.g. rails) for the rest? Or does it make more sense to stay in the Ruby world? I'm sure there are lots of caveats to this question but it would be nice to see how node.js can integrate with existing web frameworks rather than trying to build everything with node.
I've had this question myself - how much of the benefit of Node is because of Node, how much is because of JS/V8, and how much is because of evented programming generally?
For instance, if you switch from Rails to EventMachine, will you get most of the benefits of Node, or will you still be bogged down by Ruby's speed and resource consumption?
A lot of it is thanks to V8 I think.
But an issue commonly raised with EventMachine (and gevent etc. on Python) is that many common libraries contain blocking code that you cant get rid of, whereas Node modules have all been programmed to avoid blocking at all costs.
Here's one thing that never made sense to me: lets say a request comes in and data needs to be collected from 3 different sources, A, B, and C before a response can be given back to the client. You say that it would take max(A, B, C) in order to retrieve all the data. Consider this pretty standard snippet:
function get(source, callback) {
var result = getData(source);
callback(result);
}
get(A, function(result) {
get(B, function(result) {
get(C, function(result) {
// CREATE RESPONSE WITH A, B, AND C HERE
});
});
});
Wouldn't you have to wait for the data to be retrieved before running the next callback resulting in a time of A + B + C anyways? Am I missing something about the way to retrieve data from multiple sources? I don't see how max(A, B, C) is possible while still knowing for sure when all the data has been collected.
This method has basically turned an async request into a synchronous request. One idea is that you make requests A, B, and C concurrently, parse the data, then have a handler which waits for the 3 to complete and then combines them into a single response, as opposed to cascading all the callbacks.
I understand that, but I feel like a majority of the javascript async code I've seen has all been in this format. By chance, do you have an example of handler which would wait for multiple async requests to complete?
There are two distinct issues here : (a) throughput (b) concurrency -- how many concurrent incoming requests you can handle. Event I/O based frameworks help you with maximizing concurrency.
The solution that synchronous systems use is either creating more processes or threads. But the problem is you either end up wasting resources (as is the case with one process per request), or have to figure out how to share those resources concurrently without shooting yourself in the foot (and thread-safe programming isn't always easy).
For example, say your portal needs to collect info from 3 sources A, B, and C. In a synchronous system, you would have to request service A, wait for a response, then request B, wait, and so on. This means your request is utilizing the system for all that time, unable to serve other requests, without extra threads or processes.
Node, and other async systems, when they call for IO, like a service, a callback is registered for the result. So instead of having to wait for the result, the system becomes available for other actions, like other requests. So in this case you could request service A, B, and C all at once, and while you are waiting for the responses, the system can be handling other requests. When any of those services completes, it calls back to your code so you can handle the results, and give a response to the client.
So the advantage is that instead of a request taking A + B + C + extra time, it can take max(A, B, C) + extra time to serve the request, while serving other requests concurrently.
Node is not the only way to achieve this, many async systems exist like Tornado for python, EventMachine for ruby, and many others. But the JavaScript in node can be particularly fun to work with especially if you are also doing the front-end JavaScript, as it pretty much brings the context-switching in your brain to almost nothing.