Web Dynos can handle HTTP Requests
and while Web Dynos handles them Worker Dynos can handle jobs from it.
As the high-level article on background jobs and queuing suggests, your web dynos will need to communicate with your worker dynos via an intermediate mechanism (often a queue).
To accomplish what it sounds like you're hoping to do follow this general approach:
As far as actual implementation goes I'm not too familiar with the best libraries in Node.js, but the components that glue this process together are available on Heroku as add-ons.
Queue: AMQP is a well-supported queue protocol and the CloudAMQP add-on can serve as the message queue between your web and worker dynos.
Shared state: You can use one of the Postgres add-ons to share the state of an job being processed or something more performant such as Memcache or Redis.
So, to summarize, you must use an intermediate add-on component to communicate between dynos on Heroku. While this approach involves a little more engineering, the result is a properly-decoupled and scalable architecture.
From what I can tell, Heroku does not supply a way of communicating for you, so you will have to build that yourself. In order to communicate to another process using Node, you will probably have to deal with the process' stdin/out/err manually, something like this:
var attachToProcess = function(pid) {
return {
stdin: fs.createWriteStream('/proc/' + pid + '/fd/0'),
stdout: fs.createReadStream('/proc/' + pid + '/fd/1'),
stderr: fs.createReadStream('/proc/' + pid + '/fd/2')
};
};
var pid = fs.readFile('/path/to/worker.pid', 'utf8', function(err, pid) {
if (err) {throw err;}
var worker = attachToProcess(Number(pid));
worker.stdin.write(...);
});
Then, in your worker process, you will have to store the pid in that pid file:
fs.writeFile('/path/to/worker.pid', process.pid, function(err) {
if (err) {throw err;}
});
I haven't actually tested any of this, so it will likely take some working and building on it, but I think the basic idea is clear.
I just noticed that you tagged this with "redis" as well, and thought I should add that you can also use redis pub/sub to communicate between your various processes as explained in the node_redis readme.