3 ms·
> > Not true, according to here > I said public target. You are technically correct, the best kind of correct. > I didn't say CGI just stopped existing and e
by AdieuToLogic 7y ago
> > Not true, according to here
> I said public target.
You are technically correct, the best kind of correct.
> I didn't say CGI just stopped existing and emphasized commercial use - it was too slow too once you hit even relatively medium-ish traffic.
And I agreed by stating:
> And, of course, FastCGI[2] is a welcomed optimization and to be preferred, but fundamentally is just that. An implementation optimization of CGI.
For efforts which do not need to scale, "classic CGI" can be a good fit. FastCGI can help increase the scale ceiling. Proprietary extensions can further do so.
Now the industry finds itself rediscovering CGI in the form of AWS Lambda[0] and Azure Functions[1], albeit addressing traffic concerns via "the cloud."
Funny how what was old is now new, eh?
0 - https://docs.aws.amazon.com/lambda/latest/dg/welcome.html https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
1 - https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview https://docs.microsoft.com/en-us/azure/azure-functions/funct...
- pvg 7y agoYou are technically correct, the best kind of correct. Hah, no, I was the regular kind of correct, you just misread what i wrote - the best kind of read. As to the other thing, I wasn't arguing about the merits of CGI just that the commenter's recollection was a few years off. A lot of stuff happened in that '94ish-'98ish period as the web went commercial. Whether lambda is a forgotten CGI, it's a different tangent but I'm not sure I agree. The share-nothing architecture is still (give or take) the norm in HTTP request handling. CGI's attractive feature was implementation-language independence. Lamda's attractive feature is scaling independent of some big unwieldy discrete compute unit (hence 'server-less', you don't scale in servers).