Decoupling

I would like to talk to you about something that has been on my mind lately: Decoupling. No, it’s not any particularly new concept and something I’ve been practicing as a software developer over the past ten years. What I have been thinking about is its application to the web, our software stacks and how I would like to take it further in my own work.

In computer science coupling is the term used to describe how much one piece of code relies on another piece of code and knowledge about the inner workings of that code to be able to use it. Decoupling is the process of separating them so that their functionality will be more self contained.

Decoupling is a good practice as it makes the individual parts easier to maintain and change. In software development we usually start with doing the simplest thing that could possibly work. As long as something delivers what its users expect, implementation does not matter. You could start with a simple, but inefficient implementation just to get things going, and then switch to a more efficient when you need to start to scale without your users being any wiser. Put in other words: The higher degree in wich something is coupled the harder it gets to do something simple.

A motivation for decoupling in web development is friction. Friction, used more or less in the following sense was something I first encountered in a blog post by Phil Gyford. Friction is an excellent word to describe the resistance to start doing something. Be it writing this blog post, creating and improving a design or implementing a new system. Before I start work on something I tend to sense what is needed to do the job, usually stuff start to pile up and the works begin to feel overwhealming. Even the simplest thing instinctively feels hard to do. That’s friction.

The more something is coupled, the more it provides friction for me to start working on it.

To me there are currently two cases of friction due to coupling in developing for the web: Design of the front-end with templates and the relationship between the back-end and the front-end in a content management system or any complex web application.

Templates

You don’t mix business logic and presentation in a modern web application. In fact you usually separate the business logic and its constraints into a model, that is modified depending on the input by a controller and rendered by a view. The model-view-controller pattern. A way to decouple the components of an application. The problem is that not all web applications separate the view into templates as cleanly as I would wish. There is still too much logic in there, while not being business logic, it is still logic and that increase the friction to design and template the front-end.

All I want is to start write HTML, style it with CSS and progressively enhance the user experience with JavaScript without having to care about the web application or CMS. Sure, I could just start authoring regular HTML documents and convert them to the template system when I’m finished. The trouble is, you are usually never finished. Design is an iterative process.

The largest producer of friction for me right now is systems developed in PHP. They tend to use PHP as well as their template language, which is understandable as it is simple and in a sense efficient. However this means that you have to run the system to see what your templates will look like. This is not so much of a problem in development frameworks like Ruby on Rails or Django as the framework provides a simple web server that run the application during development. In other words less friction. But in PHP there is no such thing, you have to set up a separate and full blown web server environment yourself. Friction.

The solution is to use a template language that not only can be used by the web application or CMS but that also include a static page generator. Using the static page generator and dummy data as a development environment without having to run the whole system. Decoupling the template authoring from the underlying system.

This is the reason why I have been using Mustache.

There are a lot of template languages, most of them try to do too much, Mustache on the other hand, try to do less. That way Mustache takes things a bit further. All it provides is variables, iteration through lists and conditionals for sections. The source of the data is decoupled from the templates.

My initial attraction was also the fact that there is implementations of Mustache in a wide variety of programming languages. Meaning I can use it in all my projects. I can even switch programming language or mix them in a project but still use Mustache as template language and even use the same templates. A lot less friction. Don’t you say?

Linked Data

The next thing is the relationship between the back-end and the front-end. This might not matter for most simple web applications, blogs and brochure sites but for any larger operation that will use and reuse its conent in different formats and context, this become a critical component of the architecture in the long run.

The problem is that in most content management systems and other web applications the front and the back is usually tightly coupled. What I ideally want is to use the right tool and the best tools for each job. I want to use the best system to manage the back-end and the ability to create different and new front-ends. In other words decouple them.

The solution is to create an API that the back-end can provide the front-end with. To me the ideal pattern for such an API is the concept of Linked Data. The concept of linked data and the principles it is built on are fairly obvious when you start to think about it. You use URIs to identify things, as keys, and the URIs should be HTTP URIs so that they be looked up and you can get useful data back about the things in a standard format, and most importantly: provide links to other related URIs to expose more data. This is pretty much how we think the web already should work. The difference with linked data is to make sure that this is how machines also should be able to use the web.

Instead of hooking your front-end directly to a SQL database, or using some RPC calls to connect to the back-end. Why not expose your data as linked data and provide it serialized in the format or formats of your choice: JSON, XML or even human readable HTML?

If you are already planning to create an Open API for your content or service, why not use it yourself internally as part of your architecture? That way you can be asserted it will be the best API for your service as you will be your own hardest critic and super user. That is what the BBC are doing with their Programmes service. It is an Open API based on Linked Data that BBC are using themselves to power all their sites. It’s what provide data to station and program sites. It’s what the iPlayer is just a front-end for.

Be your own API client.

Putting the two together

Over the past ten years we have been used to web sites that dynamically update parts of their pages using asynchronous JavaScript callbacks to the server. (Does anyone still call it Ajax or has this become too common for a buzzword?) If you already have your content provided as linked data serialized as JSON for your regular front, you already have the data accessible in a format that any additional JavaScript-driven front end will be happy with. Less friction.

With Mustache you don’t have to parse and populate the templates only on the server side. You can do it right there in the browser using a JavaScript implementation of Mustache. That is what Twitter have been doing with Hogan.js.

How cool is that?

This entry was posted in Besserwisser and tagged , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.