What makes for a simple web application environment
Suppose that you want to create a simple web application environment, something that can compete with CGI programs and PHP to attract people who have modest needs and just want to throw something programmable up on their website. What does it need to have? As it happens I have some views on this, formed from my long run of using and abusing CGI programs (although I haven't done PHP).
In my opinion, anything that wants to displace CGI or PHP in people's affections needs to be as simple to get going as they are (see eg the attractions of CGI scripts). This means:
- A simple deployment scheme that is as close to 'copy a single
thing and go' as possible. If one step of deploying a new web app
in your system is 'edit the web server configuration file', you've
I don't think this requires an in-server environment, the way PHP
is in Apache, but I think it does require any service daemons get
auto-started and auto-reloaded and you need some simple way of
hooking it up to the main server.
These days I would hold my nose and say that the right answer for simple multi-file deployments is to let people push .zip files to the server and have the server run things from them in place (and fetch things from them and so on). Python already does this to some degree, so there's an existence proof.
- No persistent state between requests,
at least by default. Not having persistent state means that code
can still work fine even though it's sloppy, and people are going
to write sloppy code in a simple, 'get things done quick' web app
(I feel somewhat divided about this because it immediately hammers a language I rather like. Maybe you can set up your programming environment to strongly discourage global state and have that be good enough, but I'm kind of dubious. Or maybe Go will turn out to be a special case where goroutines are good enough isolation.)
- A simple and easy programming model for handling web requests in
general. My view is that inspecting an environment and printing
things out is quite simple and easy to deal with and thus the
more you depart from this, the more difficult your environment
is. A 'hello world' web app equivalent should not be very many
more lines of code than a plain command line one.
(Similarly, getting the
POSTparameters should be either dirt simple or essentially automatic.)
One important aspect of this is that the programming model should look exactly as if you're handling the request in the main web server. If the main web server forwards requests to the simple web app environment with HTTP, you must hide the seams involved here (cf). This basically means running your own custom protocol on top of HTTP to forward all of the information that HTTP will overwrite, then restoring it before people's code sees it.
The last point leads me to the view that URL routing should not be part of the basic layer of your simple web app environment to any particularly visible extent, since URL routing can get quite complex very fast. Ideally URL routing is part of the deployment process, not the coding process, in the same way that copying a CGI script or a PHP page to a particular place in the directory hierarchy does the 'URL routing' for them.
A simple web app environment can optionally provide more sophisticated features if they don't get in the way, and there's certainly a lot of long term benefit to doing so. But if you're aiming for a simple environment, start with the 'hello world' case and make sure it stays simple.
(Whether creating such a new simple web app environment is possible any more is an open question. It clearly requires significant integration with the main web server, and whether you can do that any more is an open question. CGI and PHP are both kind of relatively unique historical artifacts in Apache, after all. Maybe we're just stuck with no good general simple web app environments to complete with them.)