Apache doesn't handle large numbers of open/long-lasting connections like node (or nginx) does. Further, it will completely fail to reverse-proxy websockets (as will anything above layer 2 at this point.)

The best solution is to have your static files on a CDN.

If you're using Node as an app server in the context of a larger website with other components, yes. However, if your app is primarily Node.js driven, you may not want Apache standing in the way. Node.js is used to drive some really cutting edge services like WebSockets. I have no idea how gracefully Apache proxies something like WebSockets to a back end app server. I have a feeling the Apache worker process gets tied up for the duration of the socket session. That's not good.

If your entire website is run by your Node.js app, a better approach would be to use Node.js as your primary app/web server, and embed your static assets using a separate domain. For example, you'd use static.mydomain.com for all your static assets, which would point to Apache/Nginx, while your page requests are all handled by Node.js.

The point is that putting a Node.js server behind a reverse proxy that uses threads (or processes) for concurrency is silly, since it quickly becomes the bottleneck, negating any benefits Node's asynchronous event-driven architecture provides.

If you want to do what you're suggesting you should use an equally performant web server like nginx, which is also asynchronous/event-driven.