The value of API driven development close

For a while now we've been considering a big shift on how we approach the development of projects here at codegent. Unless we are talking about campaign driven websites with a short shelf life or extremely simple projects one of the most wasteful things I've witnessed agency side is the systematic rebuild of projects every few years. These often totally scrap all of the previous work and create complex data migration tasks or blank canvasses where old lessons will need to be relearned. Additionally, considering the recent prominent rise in apps, bolting on new interfaces to old code can be cumbersome, expensive and very time consuming. There has to be a better way and it's called API driven development.

What is an API?

An API is an Application Programming Interface. Essentially and API typically allows an external system to interact with the given system. A real world example might be the gearstick, steering wheel, accelerator etc. as APIs for interacting with your car.

Why APIs?

It's all about modularity, separation of concerns and hiding internal complexity. If different components interact with each other via APIs, then as long as the API doesn't change, components can be swapped in and out. For example, you can drive your parents volvo because the API is the same as your car.

APIs are everywhere in computer land. Modular code is easier to test, maintain and reason with. In the most part APIs are how you use other peoples' code. If someone writes a library (ideally) you just need to know the API for using that library rather than the full machinations and idiosyncrasies of the programme.

What is API Driven Development?

Developers are getting excited about modularisation again. Websites have become too complicated and we need to break them up.

Let's say we create an 'API' service to access your business logic / data, e.g. https://api.myservice.com. This API doesn't know anything much about displaying data in a pretty way for users, but it knows everything there is to know about the data itself. By designing this API we will have fully considered the data model and logic flows of your business, unclouded by issues of design, framework or CMS platform. It is pretty much impossible to work with an API without documentation so a nice by product of this process would mean intuitive docs are available to those that need to work with it. How you actually build the database and functionality behind the API is very much up to you but unless you a) make a terrible job of it or b) the technology becomes totally outdated or c) your business data / logic completely changes overnight there shouldn't be much reason for having to start from scratch on this any time soon.

There are also emerging conventions for how we should communicate with these API services. The best way is over HTTP in a RESTful manner. JSON is a nice format for data transfer. Hearing that this is how you've designed it will be music to most developers ears and integration will be much easier.

OK, we've got our API. What cool stuff can we do now?

To start with a front-end client (website) that uses the API service to display data to users and perform interactions e.g. creating, editing and deleting user accounts. The beauty of this is that the development and maintenance of the front-end client and the API service can happen completely independently as long as the structure of the API has been agreed. You just plug them together when they're ready.

Once you've established that you might want to consider additional new front-end apps. Most likely an admin app (CMS) and maybe a mobile app(s). That's fine, the API service doesn't have to change to accommodate this, you just plug them into the internet. Want to completely refresh your look and feel? No problem! Just swap out the interfaces.

Maybe other people could do something cool with your data? Just give them access to your API (you can create authorisation keys to restrict who can do this and log what is happening) and see what they come up with. Famous companies who have done this and hugely benefitted from the third party developer ecosystem include Twitter, Facebook and Instagram for logins, access to your account assets like photos, search and loads more. We've actually built a business off the back of the Twitter API for our Twitter monitoring tool Twilert and our team are about to launch another app for iPad using Instagram.

Starting out a project with a pure focus on data and logic doesn't sound like much fun but it will force you to really consider the true essence of your platform. Once defined everything else will become simpler, faster and interoperable, as well as being future proofed for when that new marketing director starts in 2 years time and wants to completely change your website :)