[hashtagmarkup]

If you're working with a stack like nodejs, I don't see how FastCGI would be any faster or better in any way.

In the late 90s I used FastCGI with Perl to basically do everything... personal sites, the local Lee Newspaper, even a math expert system funded by a NSF grant that interfaced with MatLab. Nowadays, http server extensions and cloud services easily match FastCGI performance, while providing many scaling and logging and denial of service protections and features built in. It's hard to argue for FastCGI anymore, but everyone wants to reinvent the wheel, and some of those wheels are nice. Who needs EDI when we have SOAP? Who needs either when we have REST.

[xorcist]

A fastcgi (or similar, uwsgi is great) server gives you a lot of control over the application lifetime that you have to implement on your own if you use http.

You also have less control over buffering and since you don't see the actual connection, you have to rely on special headers to get things like remote ip and remote protocol. Not a big deal, but still nice.