Fun fact: In 2020, there are still companies out there with full-blown web apps using CGI (yeah, remember? /cgi-bin?).

Do the apps work and are they secure? If yes, then who cares?

ehm... what's wrong with CGI?

@iiii Nothing, I was enjoying writing CGIs in Perl in the late '90s. In fact, I almost shed a tear when I've seen it.

The last CGI I wrote was in Euphoria. 🤭

@justamuslimguy
It's easy to miss in a "JS all the things" world; the ecosystems share quite a few of the same issues and obfuscate many of the same problems. The problems that led to CGI falling out of favor were as follows:

- is the person writing it able to secure it?
- are they performance conscious?
- are they trustworthy?

If all three weren't assured, CGI ran the risk of ruining your day. It was virtually "traction control: off"; every request started a sub-process that executed a script to handle the request. The sub-processes ran with the permissions granted to the gateway process (often root with amateur "webmasters"). That's a significant bar raiser to your application's efficacy and safety disguised as ease of use.

The big reason we moved to other tech was the ability to absorb complexity and achieve better overall performance due to the elimination of IPC and the ability to control arbitrary code's security context.

Python makes playing with servers really easy.

https://docs.python.org/3/library/...

Look at the Simple server and CGI server documentation. A few lines of code and you can have a CGI server that runs python scripts. Possibly other scripts. Have not tried that.

I have mostly played with the Python 2.7 version of this.

One of the things I maintain is an old Coldfusion system that is pretty substantial.

It still brings in lots of monies.... LOTS of monies.

@SortOfTested well, fast CGI was a thing which basically fixed the main problem.

@iiii
I personally considered process-bloat as the main problem. I don't like scenarios that mandate IPC for the same bounded context. Just my preference.

FastCGI mostly delegated ownership of the CGI processes to an application container, which added a management layer.

@SortOfTested I don't think I understand what you are implying by "same context". Do you have some specific use case in mind?

Yes, definitely. There's companies out there with way more archaic stuff than that.

@iiii
Keeping it < 1000 characters probably isn't possible. For the sake of not crushing the thread, I'll just say this:

Network IPC < File IPC < Threads < Green threads

If I have an api that provides services in support of an DDD domain (or subdomain in sufficiently large applications/microx-and-ys), that api should not require more than 1 process on a single host to handle all requests.

https://dzone.com/articles/...

@SortOfTested so how fastCGI is not being suitable here? It's one process with several threads which are not meant to involve any IPC between them.

> What's wrong with CGI?

Thread per connection is one reason

@12bitfloat *process per connection if we're talking about regular CGI.

@iiii
It really doesn't. The FastCGI module/ISAPI filter creates n-subprocesses to host as request workers. It then balances the incoming requests over the workers to achieve concurrency:

https://httpd.apache.org/mod_fcgid/...

@iiii That's even worse though

@SortOfTested oh, I see. I did not know the Apache fastcgi did that. In theory fastCGI should work as one process. Well, at least as far as I known about fastCGI.

and I was remembering things wrong. fastCGI is supposed to spawn persistent processes. I thought it was supposed to use threads.

@iiii
Yep. It's the same model as PM2, but using stdout to pass data back to its parent, as opposed to the networking stack with PM2.