6 ms·
I argued in favor of CGI scripts over a decade ago as more web work was being switched to PHP or mod_perl. Even on "slow" hardware, they could often run in abo
by markstos 3y ago
I argued in favor of CGI scripts over a decade ago as more web work was being switched to PHP or mod_perl.
Even on "slow" hardware, they could often run in about a second. Which was still fast enough for a small business with a form that gets submitted a few times per day.
For a lot of a small sites, needing to serve more than one request per second would be a great problem to have.
- gwd 3y agoRight, so maybe you can help me understand. Literally the only thing I've seen anywhere, both in TFA and in all the responses (including yours) is "CGI isn't really that slow." So that's a reason not to not use it; but are there any reasons to use it? Even in TFA, he demonstrates using a simple Golang CGI binary; but writing a simple Golang server that you pass through as a reverse proxy is just as simple.
- markstos 3y agoCGI is a good fit if you don't maintain the server it runs on. You've got a basic "user" account and can just upload a CGI script. For example, you've got a static website and need a simple contact form handler. Apache had an option to run the scripts as your user, rather than default of "nobody". That allows segmenting the processes of different users on the same server.
- anonacct37 3y agoNo memory leaks (unless you use shared memory). No weird connection pooling and caching issues or delays in picking up a config change. Every request is a fresh start, enforced by the OS. Buggy code (like image processing can only crash the current request).
- randomdata 3y agoIf you avoid writing the simple server you can assert your familiarity with serverless on your resume.