The New Client Side

What happens when you separate your client from your business logic?

I was thinking about Martin Fowler’s recent post about the Database Thaw, and was reminded of an article published by by Dave Thomas. He pointed out that we could build our clients independently from our web frameworks if we use RESTful back ends.  Such an approach gives us a number of advantages in scalability, integration, and code separation.

Quite simply, when we work in terms of resources manipulated via HTTP, we introduce a new place where we can cache data easily.  HTTP GETs are (or should be) side effect free, and can be cached, or run through a web proxy.  Frameworks are also including increasing support for caching at the HTTP level, Rails for instance is introducing more support for ETags in its next release.

RESTFul back ends also create an excellent integration point for your applications.  As Martin Fowler pointed out, they are quickly becoming a viable alternative to Integration Databases.  They also make exposing functionality much simpler, and easier to pick up, for example the Twitter REST API follows similar conventions as Harvest’s REST API, and as a result, both are fairly easy to understand.

These are great reasons to look into a RESTful back end, and have been covered a lot.  What I think has been largely ignored is the possibility of increasing code separation between the layers of your application.  Right now, a common stack looks something like this:

	Database	Business Logic	Front End
Product	MySQL, Postgres, SQL Server, etc.	Rails, Django, CakePHP, ASP.NET MVC, etc	HTML
Language	SQL	Ruby, Python, C#, etc.	Framework’s Custom View Language + HTML + Javascript

Ignoring the fact that I probably left out your favorite language or framework, there’s something weird about this picture.  While we typically have a clean distinction between our database layer and our business logic, the front end typically gets injected with a lot of support code from our framework.  There is usually a template language, and often helpers which generate support JavaScript.

Over the next few posts I am going to explore building completely separated interfaces which are backed by a simple RESTful server.  My premise is that we should be able to build simpler, cleaner interfaces, that play nicely with the web.  I’m planning on creating a backend that is as bare bones as possible, and interfaces with examples using ExtJS, jQuery, SproutCore, and possibly Cappuccino.  If everything goes well, we might just be able to add a Flex and Java client as well, who knows. Let me know if you’d like to see any other frameworks used, or if you would like to contribute one once things get going.