Why implement a web application as FastCGI rather than a new web server?

Question

I understand the purpose of FastCGI in terms of performance over other gateway interfaces. But if libraries that implement FastCGI already have to go through the painstaking measures of implementing a secure and efficient TCP service, why not just write applications as a web server? Is it less efficient for a front-end web server to implement a reverse proxy than it is for FCGI? Or is the specification for FCGI that much simpler than that of HTTP?

Answer 1

I had a web server program that I replaced with an FCGI program. Part of the reason I did it was because of the requirements of the program. It needed to run under the existing web server since doing so would require no additional configuration.

Another requirement was that it would be able to track some state values that can change frequently. The existing program wasn't very efficient, tracking these state values externally and doing a fresh load of them for every request. One advantage of an FCGI program is that it is persistent, so it could poll those state values and they would be available and ready for every request.

I didn't have to implement any of the FCGI spec, I just used an existing FCGI library and it handled all the communication with the web server for me. Compared to other applications I've written that have an embedded web server, implementing one with the FCGI library was relatively simple.

Another advantage of FCGI is that an FCGI application doesn't need to actually reside on a disk accessible to the web server. You can configure the server to establish a TCP connection to an instance of your FCGI application on another server. If you are in a situation where you can't access the web server directly, this can be very useful. Accomplishing the same thing with other methods can be cumbersome, but an FCGI application doesn't even need to be modified. Just configure the server, launch your app under the FCGI host, and you are good to go.

Yet another advantage of FCGI is that you can configure the web server to distribute requests between a preset number of instances of your application. If your web application works best by handling every request synchronously, FCGI is ideal because you can funnel every request into a single instance, and that instance can handle each request in a single loop. If you want at most 2, 3, or n instances all you need to do is change the value on the server and you can accomplish that.

So, FCGI isn't the best for every situation. It's the times you are faced with unusual requirements that FCGI is most attractive.