Hacker News Reader

Comment by jscheel | Hacker News Reader

This is pretty cool to see that LinkedIn used node.js for their mobile interface for pretty much the exact same reasons I used node for the last mobile interface I built. To echo the article's sentiment, node works really well when you are interfacing with a bunch of other services.

View on HN

Can you explain a little bit more regarding node ability to interface with services?

Let's say I have a few services, Service A that does Invoicing, Service B that does Payments, and the system has to communicate with 2-3 web-services as well. Let's say there is a need to create some sort of "portal"-ish solution (mobile or not). In this situation, what would be the advantage using Node?

Would you mind to share when Node is not the right choice as well?

I'm interested to know more about Node :)

UPDATE: Thank you for the replies.

FYI, I do understand the concept of node.js in terms of the async callback and the argument of client-side and server-side use the same code.

I'm not a heavy Rails user (more of a Java/Python guy) but when it comes to creating a typical CRUD web-app, Rails would be more productive?

I haven't used Node, but my understanding is it is event-driven and excels at asynchronous requests. So in your example, Node could asynchronously communicate with the services and raise events when each is complete. Obviously hitting each service simultaneously speeds things up dramatically, as well as being able to do other things while waiting.

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?

I've not seen anyone do a proper investigation, I definitely think it would be interesting.

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?

You could write your own way of doing it or use an existing flow control library. There are lots. :)

https://github.com/joyent/node/wiki/modules#wiki-async-flow

For a specific example, look at async.parallel: https://github.com/caolan/async

I wish I knew about this kind of thing last time I hacked on node.js... I would have had such better & cleaner code. This clears up a lot. Thanks

So I have yet to find a project to use node on, my case is mostly for Async AJAX requests.

Here's a very simple version (which I admit to still using occasionally)

  RequestHandler = {
      numberOfRequests: 3
      makeRequests: function() {
          var __this = this;
          a(function() {
              // Parse Data
              __this.completeRequest();
          })
          b(function() {
              // Parse Data
              __this.completeRequest();
          })
          c(function() {
              // Parse Data
              __this.completeRequest();
          })
      },
      completeRequest: function() {
         this.numberOfRequests--;
         if(this.numberOfRequests == 0 ) this.doDone();
      }
      doDone: function() {
        // We now have all data, do what we will.
      } 
  }
  RequestHandler.makeRequests();

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).

If you're talking to a bunch of different services, you don't want blocking I/O - Node.js is particularly good at nonblocking I/O, so it's great for gluing things from external services together.

(as always with Node, you can achieve the same benefit using nonblocking I/O frameworks for other languages, e.g. Twisted or gevent in Python, EventMachine in Ruby, etc)

I'll try dumb it down, not perfect but here goes. Node.JS is just an async framework that runs on v8. A good use-case (as you can see in the article) is for handling web requests, just like rails.

Services are software built to handle requests. You can build both consumers and providers of requests using Node.JS.

Tried to at least give you some small idea to get you started. The explanation is NOT perfect by any means. In fact I think I may have down played it. Either way, read the docs.

I enjoy Node.JS alot.

Hehe, came back 4 hours later to see that quite a few people have answered your question :) In regards to doing a typical CRUD app: I don't think there's a huge amount of work in that area yet. Geddy (http://geddyjs.org/) is a rails-esque framework, but it looks a bit stale, considering that it's only had 5 commits since the beginning of the year. I never used it though, so it might just be that it's rather feature -complete, and the developer is just being cautious about pushing to the master repo on github.

Reply on news.ycombinator.com