19th December, 2012

Building platforms (or designing for the future)

The following is based on a talk I gave at the Insites Xmas day in December 2012.

The monolithic Web

Since the year 2000, web development platforms have become increasingly powerful and secure, faster and leaner, easier and more complex, in every way imaginable.

In the Enterprise sphere .Net and Java battle it out, while Open Source minnows based on Python and JavaScript dart nimbly forwards. PHP based solutions provide a low barrier to entry for anyone with access to some hosting and the willingness to get stuck in.

Although the platforms have become more refined, secure and generally better over the last decade, they have shared a common trait which I believe will cause developers considerable pain over the coming years: it's too easy to create a monolithic application.

Monolithic: formed of a single large block of stone - Google

Even when following best practices and guidelines, separating the logic into projects, tiering the applications so our front-end does not talk to the database directly, all too often we end up deploying our web app into a single folder on the server and thinking we're done.

This is not future proof.

The dissolving Web

Between 2001-2004 I developed a geographically aware, on and offline, mobile-based platform designed for non-technical people to use. The users loved the applications, but the technology sucked (we were using Windows CE) and when the project was built I left the company and swore off mobile. However, this experience had planted the idea in my mind that in ten or twenty years time, computers will have disappeared from the landscape as we know it.

It is now nearly 2013 and that time is rapidly approaching. Mobile now accounts for over 50% of all web traffic. This landscape is vast, from high-spec tablets to Javascript powered phones, TVs with browsers to touchscreen kiosks, and it's growing fast.

With portable device uptake comes the explosion of "apps". Discounting games, almost all apps require a connection to an online server to perform their functions. Whether native iPhone apps or HTML5 and Javascript, these apps still offload a large amount of functionality onto online servers or into "the Cloud".

The web used to be a publishing platform, now it is also a data transport layer. Small packets of XML or JavaScript Object Notation (JSON) can be transferred over the slowest network connection, while advances in interface design mean people don't merely find these apps useful, they love them because they are easy to use and look amazing.

Build an API for yourself

An increasing percentage of online users will access the web solely on mobile. This means developing across platforms has become an accessibility concern. If you build solely for iOS, you are making a statement that you actively discount those who cannot afford an Apple product.

This might be acceptable if you develop a video player which needs the power of an expensive consumer item, but if you are providing a service which may effect people's lives, such as contact numbers for a hospital, you need to be at least useable on the worst available platform.

The iPhone was released in 2007, five years ago. We can only imagine what we'll have in five years time, whether it's embedded devices in our cars or fridges or in the walls - Smart Devices Which Do Things. We can assume they're going to need to communicate with the web and possibly each other.

When building our platforms, we need to be writing small, specific modules, communicating using open protocols. By separating out the functionality, we release ourselves from the monolithic structure and reduce internal dependency.

Creating common APIs for the platform to communicate with internally forces us to think about the data getting passed around. Only send as much as you need and maintain referential integrity inside your services. Your basket service for an e-commerce site should not care about the ID of the user in a database, because that should be handled by the authentication platform. This is a trivial example, but you should get the picture.

Once the logic is separated out, it becomes trivial to develop apps for the future wave of devices. JSON, XML, HTTP, Javascript, HTML, these technologies are not going away any time soon. Then we can build for the platform of the future!

Excited? You should be.


The opinions expressed here are my own and not those of my employer.