CGI programs have an attractive one step deployment model

January 23, 2024

When I wrote about how CGI programs aren't particularly slow these days, one of the reactions I saw was to suggest that one might as well use a FastCGI system to run your 'CGI' as a persistent daemon, saving you the overhead of starting a CGI program on every request. One of the practical answers is that FastCGI doesn't have as simple a deployment model as CGIs generally offer, which is part of their attractions.

With many models of CGI usage and configuration, installing a CGI, removing a CGI, or updating it is a single-step process; you copy a program into a directory, remove it again, or update it. The web server notices that the executable file exists (sometimes with a specific extension or whatever) and runs it in response to requests. This deployment model can certainly become more elaborate, with you directing a whole tree of URLs to a CGI, but it doesn't have to be; you can start very simple and scale up.

It's theoretically possible to make FastCGI deployment almost as simple as the CGI model, but I don't know if any FastCGI servers and web servers have good support for this. Instead, FastCGI and in general all 'application server' models almost always require at least a two step configuration, where you to configure your application in the application server and then configure the URL for your application in your web server (so that it forwards to your application server). In some cases, each application needs a separate server (FastCGI or whatever other mechanism), which means that you have to arrange to start and perhaps monitor a new server every time you add an application.

(I'm going to assume that the FastCGI server supports reliable and automatic hot reloading of your application when you deploy a change to it. If it doesn't then that gets more complicated too.)

If you have a relatively static application landscape, this multi-step deployment process is perfectly okay since you don't have to go through it very often. But it is more involved and it often requires some degree of centralization (for web server configuration updates, for example), while it's possible to have a completely distributed CGI deployment model where people can just drop suitably named programs into directories that they own (and then have their CGI run as themselves through, for example, Apache suexec). And, of course, it's more things to learn.

(CGI is not the only thing in the web language landscape that has this simple one step deployment model. PHP has traditionally had it too, although my vague understanding is that people often use PHP application servers these days.)

PS: At least on Apache, CGI also has a simple debugging story; the web server will log any output your CGI sends to standard error in the error log, including any output generated by a total failure to run. This can be quite useful when inexperienced people are trying to develop and run their first CGI. Other web servers can sometimes be less helpful.

Comments on this page:

By Andrew at 2024-01-24 00:10:28:

Apache used to have this with mod_fastcgi (which was written by the original creators of FastCGI) but it's been unmaintained for... a decade, maybe closer to two decades, and the approved replacement (mod_proxy_fcgi) is less ergonomic.

For better or worse, that whole model of doing things is out of fashion. We run our apps as full-on servers now, rather than letting them be hosted by a "real" webserver — and although there's some value in the part-way approach that FastCGI allows (where the app is able to run outside of the webserver, and privilege-separated from it, but still sees an environment like it was hosted by the server), most people aren't really keen on the benefits (like not having to deal with X-Forwarded-everything or path remapping). They just see FastCGI as a niche protocol with no real reason to exist, and would rather proxy HTTP requests over HTTP.

By Blair at 2024-01-24 04:33:11:

This made me interested as I used to regard CGI as slow, because each invocation is a complete process lifecycle. Or is the CGI process started and kept in there, acting like a REPL but for requests and responses? Caches in play?

PHP has traditionally had it too, although my vague understanding is that people often use PHP application servers these days.

We are certainly using php-fpm to run things. We have this PPA which is one a2enconf php8.2-fpm away from providing PHP service in the classic model. Although I'm pretty sure we customize the fpm/pool.d/www.conf file as well.

I believe Apache resolves the URL to a file, then passes that through to PHP-FPM for execution.

Thus, initial setup of PHP is two-stage, but then it runs like a classic mod_php setup, running anything named *.php through the default pool.

Caveat: It's all code we own, so we haven't worried too hard about isolation between vhosts. It might not be possible to set this up for user dirs.

By cks at 2024-01-24 16:52:38:

The FastCGI protocol and its equivalents (such as the much simpler SCGI) put 'CGI' in their name not because the normal model of how their servers worked was like CGI, but because they intended to give the code running in their application servers an environment that often looked a lot like CGI, with headers pre-parsed and extracted for the code and so on. Mechanically your typical FastCGI application server pre-loaded your code at startup (or, hopefully, on hot reload) and then executed it either in newly forked processes or in threads as (FastCGI) requests came in from the web server.

(A still in use logical relative of FastCGI/SCGI is Python's WSGI. Like FastCGI, SCGI, and CGIs, WSGI applications receive header information from the request, along with metadata, in the form of an 'environment', basically key/value pairs, instead of having to parse HTTP headers or something more structured. The WSGI application server that runs your Python WSGI application may well generate the WSGI environment by parsing all of the HTTP headers, but that's not your application's concern.)

Written on 23 January 2024.
« Desktop PC motherboards and the costs of extra features
The cooling advantage that CPU integrated graphics has »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jan 23 22:55:08 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.