Question

I’m a PHP web application developer that has built several large projects in PHP w/ CodeIgniter. PHP has always gotten the job done, but now I’m working on a new project that I’m building with the javascript extjs4 framework on the client-side. And I have some questions for experienced nodejs developers.

In my most recent PHP project, a user-login request required my server to make an API call to Facebook. The way I handled this, to improve scalability, was my client would make the initial login request, the server would pass the request to a ‘gearman’ job queing server, and a background worker process would grab the job and perform the API call. In the meantime, the server would reply to the client and then the client’s browser would start polling the server with AJAX to see if the job had completed. (Oh, and I passed the results of the Facebook API call from the worker to the application server with memcached). I did this to free up my application servers to handle more concurrent requests from users since PHP is locking and a Facebook API call takes several seconds.

My question is, does this whole model of App servers, a gearman job queing server, and background workers make sense for nodejs development since nodejs is non-locking? Would I simply accept an ajax request from the client to login, call the facebook API from the application server and wait for it’s response (while handling other user’s requests since nodejs is non-locking) and then reply to the user?

I’m also considering getting into nodejs development for the sake of being able to take advantage of the awesome heroku environment.

Answer 1

The short answer is yes, the way you would typically handle this in a node system is exactly how you describe it.

Because node is non-blocking, the event-loop is constantly on the lookout for actionable requests. Here’s an example using node-facebook-client (one of many npm modules built to be used with facebook APIs)

  console.log('start');

  client.graphCall(path, params, method)(function(result) {
    // fires whenever request is completed
    console.log('facebook returned');
  });

  console.log('end');

Outputs

  start
  end
  facebook returned

As you can imagine, this is basically what all the fuss is about with node (plus it’s really really fast). That said, it’s also where the learning-curve is with node — asyncronous execution. If ‘end’ needs to come after ‘facebook returns’, then you’d have to put it in the callback

  console.log('start');

  client.graphCall(path, params, method)(function(result) {
    // fires whenever request is completed
    console.log('facebook returned');
    console.log('end');
  });

Additionally, it’s elementary to integrate dynamic child processes into your application when it is needed, including additional node processes. From the official docs for child_process.fork:

var cp = require('child_process');

var n = cp.fork(__dirname + '/sub.js');

n.on('message', function(m) {
  console.log('PARENT got message:', m);
});

n.send({ hello: 'world' });

And then the child script, ‘sub.js’ might look like this:

 process.on('message', function(m) {
   console.log('CHILD got message:', m);
 });

 process.send({ foo: 'bar' });

In the child the process object will have a send() method, and process will emit objects each time it receives a message on its channel.