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.

8 Comments

Filed under HTTP, REST, Web Development

8 responses to “The New Client Side

  1. endofline

    By the way, if anyone has a suggestion for a good sample back end, let me know. Otherwise it’s going to be something horrible like TODOs😉

  2. John R

    haha, I can only imagine the links you will get for a “good sample back end”

  3. endofline

    Heh, should probably have been back-end I suppose. Well, bring on the blog spam then.

  4. LM

    Hm, no fancy idea for a sample app, but for a really simple JSON+REST server, Halycon ( http://halcyon.rubyforge.org/ ) might be worth a look.

  5. I’ve been building an app with this architecture for some months using Perl’s Catalyst framework to serve JSON. The front end is purely ExtJS. Ext has every component you could think of to build a complete user interface suitable for business applications.

    Couch DB looks like it will be a perfect back end. Schema-less, if you need it to be. Can be hosted locally on the client , for offline use of your app.

    Seriously hot.

  6. Hey Adam I was wondering if you had the the code for your multi stage wizard still? I have it all except for wizard.rb in the lib folder. Man it sure would be useful.

    Thanks,
    Jared

    • endofline

      I’m afraid I don’t work for TRAC anymore. It looks like our old SVN server got shut down, or has been neglected for too long, and I never needed that code after the project I wrote it for. I strongly suspect it would not work in Rails2.x anyways though, sorry.

  7. If you are going for best contents like me, only visit this site
    everyday because it presents feature contents, thanks

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