Remember FastCGI? (2021)

  If you find yourself with a scripted language where processing HTTP requests might be too slow or unsafe, I can still see some utility for FastCGI. For most of the rest of us, HTTP won, just write little HTTP webservers.

Without serious development effort, I would expect using an existing web server with FastCGI is faster than writing your own web server. It is also more secure as the FastCGI application can be run as a different user in a chroot, or a namespace based sandbox like a docker container.

I was thinking that.

Was FastCGI a child of a world where we had neither good library use ("import net/http"), nor (much) layering in front of the server (balancers / cdns / cloudflare etc). So it made sense to assume a production-level layer on the box itself was always needed?

I remember the vigorous discussions comparing security of Apache vs IIS etc

Using HTTP does not preclude having a reverse proxy. So the only difference between FastCGI and HTTP is really what protocol your proxy and your application use, and I don't really see why FastCGI would be major win there.

Partly.

But I suspect it's more that CGI was the way things had always been done. They didn't even consider doing a reverse proxy. They asked the question "how do we make CGI faster" and so ended up with FastCGI.

Other developers asked the same question and ended up making mod_php (and friends), embedding the scripting language directly into the web server.

Iirc most of the content was static html/css in those days. Running code on a request was rare so cgi was like a bolt on to a static content server. It was available but not the norm. Perl and php gradually made it the norm to run code on every request.

I remember in the very early days as a hobbyist working with cgi perl scripts for forums or guest books where the script just edited the "static" content in place.

The script would write new html files for new posts and do "fun" (I mean, terrifying) string manipulation on the main index to insert links to posts etc. Sometimes they used comments with metadata to help "parse" pages which would see edits.

These both were, and definitely were not, "the days" :D

Sure beats maintaining a custom webserver written in C!

This is exactly why my web dev company used FastCGI for all our development and would still today if I didn't retire it just two years ago.

Wherever we needed faster interaction, FastCGI did the job and allowed us to interface with anything in the backend including our C programs.

Given that the article’s comparison is between a HTTP server with fastCGI, and writing a little HTTP server, the web server with fastCGI will scale better, contrary to what the article suggests. It also would likely be more secure. Reverse proxies are tangential to this.

Why did you retire it?

My biggest customer was a national restaurant chain that thought they should have it all in house. So far, a big mistake.

My second biggest customer went out of business. Which left us with a bunch of itty-bitty businesses that I'm just too tired to be chasing after.

I just this week implemented an SCGI server, its even easier than FastCGI and the performance difference is arguably negligible.

The parser ended up being 30 lines of code.