I built a billing site for my software business and had to decide which tech to use. SPA? React + Rails? Elixir? Keep in mind we are talking about single digit req/min.
I went with CGI. It has some drawbacks but consider the advantages:
* Requires nothing but Apache running, minimizes attack surface area
* Deploy is a simple `git pull`, no services to restart
* No app server running 24/7 so I don't have to monitor memory usage or anything else.
I love it. Takes little to no maintenance because it never changes. Runs on a $5/mo droplet.
I'm not about to dictate to someone that their choices are better nor worse than anybody else's but I don't think you make a particularly convincing argument in favour of CGI:
> Requires nothing but Apache running, minimizes attack surface area
Sure, but the attack surface remaining (CGI) is far less secure than pretty much everything else out there.
> Deploy is a simple `git pull`, no services to restart
Same could be said for a dozen other service side frameworks.
> No app server running 24/7 so I don't have to monitor memory usage or anything else.
I mean, if you exclude the server you're talking about, then sure. But you still have a server running 24/7 that you need to monitor so the framework becomes somewhat irrelevant from that perspective.
---
Personally I still use CGI for personal projects I hack together. But none of them are directly open to the internet.
Apache httpd 2.4 can be chrooted (maybe 2.2 as well? Or at the very least some distros back ported that feature to 2.2) but it's not enabled by default and can take some set up to get working properly if you're not a seasoned sysadmin.
chroot is definitely not common amongst Apache installations, let alone common amongst CGI usage (which likely comprise of more than just Apache httpd users).
However one blessing is at least the execution directory is limited to /cgi-bin (even if software running inside cgi-bin can fork their own processes outside of that directory).
It's also worth noting that "efficient" is a poor choice of words for CGI - be it in the context of security or it's more common usage in terms of performance. CGI work by forking processes (which is slooooow). In fact CGI is ostensibly a $SHELL for HTTP (if you look at the mechanics of how shells are written vs how CGI works). Someone elsewhere else in this discussion described CGI as a "protocol" and I wouldn't even go that far because all the HTTP headers and such like are passed to the forked process via environmental variables. In fact could literally set the same environmental variables in Bash (for example) and then run your CGI-enabled executable in the command line and get the same output as if you hit httpd first.
But as I said in my first post: I don't hate CGI. Far from it, it's been a great tool over the years and I still use it now for hacking personal stuff together. But it's also not something I'd trust on the open internet any longer. It's one of those cool pieces of tech that simply doesn't make sense on the modern internet any longer (like VRML, Sockwave and Flash, the web 1.0 method of incremental page loads (I forget the name), FTP (that protocol really needs to die!) etc.
True but considering most peoples use of CGI is without a framework (otherwise you might as well just use that framework as the HTTP server) you're then having to place a lot of trust in the developer not to accidentally foot-gun themselves.
It's like the Rust argument. Sure, a skilled developer could write good code in C++ but languages like Rust make it harder to accidentally foot-gun yourself and more obvious in the code when you do happen to do it.
> Sure, but the attack surface remaining (CGI) is far less secure than pretty much everything else out there.
That is completely false. CGI has basically no attack surface. And personally, I trust Perl or C or even bash (which do have an attack surface) more than I trust all these random frameworks.
> I mean, if you exclude the server you're talking about, then sure. But you still have a server running 24/7 that you need to monitor so the framework becomes somewhat irrelevant from that perspective.
Except oftentimes these days you need both an HTTP server and an app server (as mentioned). CGI only needs an HTTP server.
> That is completely false. CGI has basically no attack surface. And personally, I trust Perl or C or even bash (which do have an attack surface) more than I trust all these random frameworks.
While you're technically right that CGI doesn't include Perl/C/Bash, it feels like you're hand-waving somewhat to avoid discussing the real crux of the problem. Having spent a significant amount of the last 30 years writing software in Perl, C and Bash (languages that I genuinely do enjoy coding in too), I honestly don't trust anyone's ability to knock their own framework out as securely as many of the established frameworks already out there.
There's all sorts of hidden traps in those languages themselves, hidden traps in the way the the web behaves as well as bugs you could introduce just through human error.
CGI is fun for hacking stuff together but if you're building anything for public consumption - even if it's only going to be a low hit count - then you have to consider what damage could be done if that machine was compromised (though it's prudent to follow that train of thought regardless of the framework you end up on).
> Except oftentimes these days you need both an HTTP server and an app server (as mentioned). CGI only needs an HTTP server.
Except oftentimes you also don't. And even in the instances where you do, often something like S3 or some CDNs will fill the role (as often it's just static content you need hosting and some CDNs allow you to manually transfer content). Or if a CDN isn't an option and you do need a webserver + app server (eg nginx + php-fpm) then you can run them as two docker containers (for example) on the same server....and even if that isn't an option, it's really not that much more work monitoring 2 servers than it is 1 (if you were talking about a farm of dozens or more then you'd have a point. But then CGI also becomes a clear no-go because of it's performance penalties).
My point is there are a breadth of options out there these days and CGI rarely stacks up well against them.
It is common for noobs to put index.cgi (or whatever) in the root of the git repo, and to point Apache at that by cutting and pasting a hello world example from google.
A better approach is to put it in a subdirectory, and RTFM of Apache/nginx.
I went with CGI. It has some drawbacks but consider the advantages:
I love it. Takes little to no maintenance because it never changes. Runs on a $5/mo droplet.https://www.mikeperham.com/2015/01/05/cgi-rubys-bare-metal/