Hacker News Reader

Comment by markstos | Hacker News Reader

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.

View on HN

Right, 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.

CGI 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.

No 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).

If you avoid writing the simple server you can assert your familiarity with serverless on your resume.

Reply on news.ycombinator.com