Besides some experience with Node.js enough to write the book linked in the side bar, I've also spent a lot of time building and configuring Drupal websites. I've been pondering the possibilities for marrying Node with Drupal and have also seen a few projects spring up with that purpose. However the core issue is that Drupal page processing is not an asynchronous process like Node's query handling, instead Drupal implements the typical synchronous start at the beginning and go to the end step by step model. You know, the model we're trying to get away from by adopting Node.
Four Kitchens is one of the big Drupal development shops, and Elliot Foster posted recently on their blog a sketch of an idea for using Drupal and Node together. See http://fourkitchens.com/blog/2012/02/07/nodejs-drupal
Because the post is focused on talking to Drupal developers, it spends the first half of the writing discussing what Node is, and what asynchronous programming is.
Elliot then suggests one plausible use is for Node to be a back end gateway to some third party API service.
The problem, as he says, is that a third party API service can be slow. This doesn't have to be a third party service, right? Any back end API service could be slow. In any case, because Drupal uses a synchronous model, if the Drupal page load accesses a slow API service, that slow service will slow down rendering the page from Drupal and give a bad user experience.
He suggests a Drupal 7 mechanism called "Drupal Queues" which is an object model inside Drupal to store a queue of requests that will be handled at some later time. I don't know much about this, but clearly it's a bit of a hack necessary to overlay some form of asynchronocity on Drupal.
In any case it would let a Drupal page request foist a request to a third party API to a Node.js based gateway widget, the Node based widget will immediately reply that it got the request, and the Drupal page processing will proceed on with building the page. Some time later when the third party API replies to the Node based gateway, the gateway will turn around and notify Drupal.
The implementation will be some little service sitting on http://localhost:port/path that implements the proxy/gateway to the third party API.
Four Kitchens is one of the big Drupal development shops, and Elliot Foster posted recently on their blog a sketch of an idea for using Drupal and Node together. See http://fourkitchens.com/blog/2012/02/07/nodejs-drupal
Because the post is focused on talking to Drupal developers, it spends the first half of the writing discussing what Node is, and what asynchronous programming is.
Elliot then suggests one plausible use is for Node to be a back end gateway to some third party API service.
The problem, as he says, is that a third party API service can be slow. This doesn't have to be a third party service, right? Any back end API service could be slow. In any case, because Drupal uses a synchronous model, if the Drupal page load accesses a slow API service, that slow service will slow down rendering the page from Drupal and give a bad user experience.
He suggests a Drupal 7 mechanism called "Drupal Queues" which is an object model inside Drupal to store a queue of requests that will be handled at some later time. I don't know much about this, but clearly it's a bit of a hack necessary to overlay some form of asynchronocity on Drupal.
In any case it would let a Drupal page request foist a request to a third party API to a Node.js based gateway widget, the Node based widget will immediately reply that it got the request, and the Drupal page processing will proceed on with building the page. Some time later when the third party API replies to the Node based gateway, the gateway will turn around and notify Drupal.
The implementation will be some little service sitting on http://localhost:port/path that implements the proxy/gateway to the third party API.