I have an idea (oh no not another) that draws on a number of different things that seem to be coming together to offer hope of a new architecture for developing and deploying web applications. One that offers a richer experience for the user coupled with more flexibility and resiliance for developers and administrators...
yes it's a magic bullet ;-)
No, more seriously. I have been thinking about how the following connect:
- REST based servers
- XMLHttpRequest based web browser UI's see 42: Auto complete comes of age - SitePoint DHTML & CSS Blog and 42: Joel on Software - Wednesday, December 15, 2004 and 42: Rest Fest.
- Tim Bray's comments on threading for multi-core servers ongoing: Software in the TLP Era.
- Jon Udell's comments on tiny http servers eg The present and future value of Python and XML.com: Lightweight XML Search Servers.
- The problems the SpreadFirefox website had with bandwidth which required all images to be handled by a sub-domain. (42: Notice: Please change your affiliate image links - Spread Firefox)
- The cost of hosting dynamic sites for charities, when you want to go beyond php or mod_perl.
- The announcement of version to 2 of Sleepycat Software: Products: Berkeley DB XML
- Joel on Software - Friday, December 10, 2004. (Google Suggest raises the bar for web apps)
So my thinking is to split up the application into chunks that are hosted separately.
- Static html (and images, but put them on a sub-domain from the start).
- A variety of small http servers handling simple REST api's
You will need a core REST server to handle security and the various other REST servers will need to use a REST API themselves to check permissions etc.
We have seen a number of ways that web sites include bits of dynamic content from other sites in the side bars etc (ads, weather, clocks, blogrolls ...). Now I am suggesting that we build entire web applications this way. It means taking the server part described in model N of Serving Client-Side Applications (my earlier comments at 42: Serving Client-Side Applications) and splitting it into those bits that can come from static hosting solutions and the REST bits that do not need to come from a single server.
When you run applications like this on your intranet it gives you the ability to make use of all those threads your multi-core processor offers, even when using a programming language like python where each instance does not thread very well. (eg lots of small http servers running small parts of the REST api). I have been reminded recently how much smaller and simpler a REST based application server is than a full html application server. Moving client state and presentation out of the server really simplifies things.
In fact if you look at some of the work being done with Inspirational Technology: Introducing Syncato and Sleepycat Software: Products: Berkeley DB XML and by Jon Udell the http server almost disappears as the rest api maps almost directly onto the XML database.
You should be able to rent significant chunks of functionality yet have total control over the user experience.
I suspect the key challenges to be resolved are:
- Security: common practices needed
- The move away from a single SQL database containing everything. Now your reporting gathers data via REST from a variety of sources. Maybe you gather from a variety of transaction processing databases into a single analytical database.
- Fear of lack of control.
What does anyone else think? Have I been drinking too much coffee or eating too much turkey?