This is related to another question specific to payment processing, and that is my example use case, but I was considering trying to integrate node.js and ruby on the same server using beanstalkd. Basically, I want to use node.js as my main web server, but when I need to do some payment processing, I'd like to use something robust and stable like ruby.
I was considering trying to use beanstalkd as a way to have node.js queue up payment processing jobs for ruby to perform in the background. The documentation for beanstalkd is a little slim, so I'm having trouble figuring out if this is a good approach, or exactly how I would go about it. From what I can tell though, it should be fairly straightforward to start a beanstalkd process and then have node.js connect to it to send it jobs, and have a ruby script which can perform the jobs and send back the results.
So after rooting around enough, I did find the documentation I really needed to evaluate beanstalkd. There is a protocol document in the source not linked to from anything I've been reading or the main page (although it is in a folder called doc) that gives better details about its capabilities and limitations.
It seems very nice as an asynchronous worker queue, which is perfect for node.js, and it would be a good fit to communicate with some Ruby code to do payment processing, but as dkam says, how do I get the response back to node.js to be able to update the client. While I think this makes sense for many tasks, it is not sufficient for mine.
Given alfred's advice, I've investigated redis, and while it isn't exactly what I need right out of the box, I think it will be sufficient. There is already an actor library out there built on top of redis for Ruby, so I think I should be able to make something simple that can talk between node and Ruby with roughly actor style semantics, or at least callback semantics.