The reason we stopped using it 15+ years ago was performance: forking a new process for every incoming web request just didn't make sense on ~2000 era hardware.
I wonder how true that is today, given that our machines have vastly more RAM and CPU?
If you squint at them the right way AWS Lambda functions are pretty similar to the CGI model.
- 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-...
> 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?
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.
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.
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.
2000 era CGI tended to be in Perl or PHP. Even then Java made an appearance, with a long-lived host process, e.g. Websphere.
One advantage which the author gets right is that CGI consumes no resources while not serving requests, so you can have a lot of different CGI programs on the same machine. It also plays nicely with multi-user systems, so an ISP could host a lot of different customers on one box. We could serve CGIs from several hundred users off a 128MB Pentium system, for significantly less resources than one Slack instance.
I see that starting up a Python interpreter and running a Python program (or Ruby or whatever…) might be slow, but how far can I get with a golang, C or ocaml binary?
I don't know, but I'd expect the Linux people to have optimized that to death.