Maybe current web servers are written in such a way that they do cut connections between CGI requests, but I’d be surprised if they really have to.
With CGI, any connection you create in your script is going to close at the end of the request when your process shuts down.
There are alternatives; even back in 2000 you'd keep the stuff you wanted cached in the filesystem, where the webserver would handle the cache headers for you, and there are ways to hook a cache miss by the webserver to generate content on demand.
That's fine, they can keep. TFA suggests using CGI in lieu of modern frameworks, not WITH modern frameworks.
>- it prevents any form of caching. caching is very important for many use cases.
No, it really doesn't. You can cache whole responses with a reverse proxy on top, or you can cache complex results in whatever (Redis, disk, etc) and query it from the CGI program.
>- it requires to open a fresh connection with every request, to the database and elsewhere
Which might be fine. MySQL for example is notoriously cheap to connect to for each request. Redis as well. (And you can always bump CGI to FastCGI).
>- SSL is everywhere and it has a notable overhead on initialization, meaning you really wish you could reuse connections
You can terminate SSL on your proxy, so that's not a issue.
> it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis for caching).
nutcracker, twemproxy?
- modern frameworks have a much higher startup time (see Python imports, Java VM and other). CGI was fine to run a perl script with no dependencies.
- it prevents any form of caching. caching is very important for many use cases.
- it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis for caching).
- SSL is everywhere and it has a notable overhead on initialization, meaning you really wish you could reuse connections. (Not just the databases but to other API services)
Speaking from experience, I've inherited the CGI platform at JP Morgan (the largest US bank), that went back to 2006 and approached a thousand running applications at some point. It works and it was still the easiest way to deploy any application in 5 minutes 2 decades later but the drawback are real. It's only for short scripts that can tolerate a 5 second startup time and zero caching.
https://thehftguy.com/2020/07/09/the-most-remarkable-legacy-...