5 ms·

It's unusable today, more so than it was a decade ago: - modern frameworks have a much higher startup time (see Python imports, Java VM and other). CGI was fin

It's unusable today, more so than it was a decade ago: - 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-system-i-have-seen/ https://thehftguy.com/2020/07/09/the-most-remarkable-legacy-...

bawolff 5y ago
> 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). nutcracker, twemproxy?
- swamp_gas 5y ago
  apache caching reverse proxy even.
  - bawolff 5y ago
    From context i assume the poster meant object caching, since the cgi model wouldnt affect client caching or cdn style front-end caching.
loup-vaillant 5y ago
Wait a minute, how CGI is preventing anyone from reusing connections? The web server doesn’t have to cut connections between CGI requests, the same way it doesn’t have to cut connections between the delivery of two different static files. 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.
- TheCoelacanth 5y ago
  They aren't talking about client->server connections but about server->DB or server->other server connections. With CGI, any connection you create in your script is going to close at the end of the request when your process shuts down.
coldtea 5y ago
>- modern frameworks have a much higher startup time (see Python imports, Java VM and other) 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.
pjc50 5y ago
> prevents any form of caching. caching is very important for many use cases 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.

bawolff 5y ago

> 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). nutcracker, twemproxy?

swamp_gas 5y ago
apache caching reverse proxy even.
- bawolff 5y ago
  From context i assume the poster meant object caching, since the cgi model wouldnt affect client caching or cdn style front-end caching.

loup-vaillant 5y ago

Wait a minute, how CGI is preventing anyone from reusing connections? The web server doesn’t have to cut connections between CGI requests, the same way it doesn’t have to cut connections between the delivery of two different static files. 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.

TheCoelacanth 5y ago
They aren't talking about client->server connections but about server->DB or server->other server connections. With CGI, any connection you create in your script is going to close at the end of the request when your process shuts down.

coldtea 5y ago

>- modern frameworks have a much higher startup time (see Python imports, Java VM and other) 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.

pjc50 5y ago

> prevents any form of caching. caching is very important for many use cases 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.