Building the hackable web.

One of the things that has been on my mind latey is how you architect for a Web 2.0 and beyond world. If I look at the architecture of your average every day .NET application today, particularly where there is a server side component you will generately see that it is broken down into multiple tiers (well, layers actually, but lets not argue semantics).

With most ASP.NET web applications you will find a front end which calls through to some kind of business logic or workflow layer (often just pass thru – but it might not be one day, yeah right), and then down to some kind of CRUD layer, which may or may not have been code generated.

Now, the thing that was thrown into just about every n-tier design document I ever saw was that “the business” might one day want to re-skin their application, at which point all you would have to do is make the new UI talk to the underlying business logic or workflow layer. In essence, the business logic/workflow layer was the “level of hackability” in the application – its the thing you could repurpose for your own nefarious purposes (note to self, I don’t use the word nefarious often enough).

Now the thing about Web 2.0 is that you are trying to open yourself up to mash-up possibilities without the people producing the mash-up having to force you to make changes. Unfortunately, if your level of hackability is below the web-layer in your application then its going to be hard to do becuase the UI will be locked up so tight (probably by design) that others can’t plug you in.

What needs to happen is that the level of hackability in your application needs to be pushed up a layer so that all and sundry can see how to jump into your site and pass data into it, typically via a POST or a GET.

Of course, one of the challenges for people doing mash-ups is that its hard to go-sub-without-return so if you REALLY want to get people mashing-you-up you need to offer additional hackability features. One really useful thing that I think would be useful on a lot of sites is the recognition of a “ReturnUrl” query string parameter. We use this all the time to support authentication within a site, but what about if we want to use it to support bouncing back to someone who is mashing you.

This post is certainly not an indepth analysis, but I think that what is clear is that as we drive towards building more online applications that we actually need to step back and think about whether our existing architectures necessarily graft cleanly onto the web.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s