Correct me if I'm wrong but by the time .htaccess is processed to see where to route the user to, you're already using Apache resources.
So while you can run the two together like this, Node.JS will ultimately be confined to the same scale limitations as Apache. So you lose a lot of the benefit.
That's right, you tie up an Apache process/thread to proxy each connection, so pretty soon you run out of them. And the whole point of Node.js is to run I/O asynchronously without tieing up a thread for it.
A better alternative would be to run e.g. Varnish in front of both Apache and Node.js. Then you can forward requests to any backend server you like in an efficient manner (using pipe mode for long polling requests).
Varnish is good unless you need SSL. IIRC Varnish still doesn't support SSL, and the author never intends it to. I'm not suggesting that's a bad thing, just saying.
Apache is probably not the best choice to use as a reverse proxy to Node.js. One would probably have better luck with Nginx or something with a similar asynchronous design as node.
So while you can run the two together like this, Node.JS will ultimately be confined to the same scale limitations as Apache. So you lose a lot of the benefit.
Or am I wrong?