CGI is dead, long live CGI
Yesterday's (not so pleasant) experience of trying to deploy Pastedance *) on an internal web server at work makes me appreciate the simplicity of CGI. CGI might be out of favor for production sites, but for personal and internal applications, it's still the best choice for me.
- There's no daemon. No slowly-but-ever-growing process that eventually gets killed or thrashes the server (thus, no need to configure ulimit/rlimit, or write another script to monitor this, or add a condition in code to exit periodically). No need to worry about memory leaks. No need to manage and monitor daemon process. No need to put startup script in cron, /etc/init.d/ or whatever. You can be as dirty or one-off as you want. (Of course, you don't always want to be dirty, but the fact that you can is great.)
- Works with any webserver. Works with any standard Linux server, like a plain Debian with Apache.
- Can be isolated easily. Run as each user. Run as nobody. Run as per-user nobody.
- Can be upgraded to FastCGI usually with very minor modifications (with caveat).
- You can run hundreds of applications/sites simultaneously on a single server. It's the shared hosting owner's dream.
- Did I mention there's no daemon? I can't tell you how much I, and fellow sysadmins, love it.
Unfortunately, Dancer is too slow if deployed as CGI. Each request takes one to a few seconds and this becomes unbearably slow since every image and CSS file is routed through it.
I am under the impression that CGI::Application is the only "current" web framework usable under CGI. But I understand that it's very minimal, perhaps even to my taste. If I were to write yet another web framework, one of my design goals would be to make it usable under CGI. But I really, *really* do not want to do that.
*) On another note, does anyone know of a pastebin webapp that you can install in 1-5 minute on a plain Debian server with Apache? Not necessarily need to be in Perl. Preferably runs under CGI and uses MySQL/PostgreSQL/plain text files.