There are tonnes of different development methodologies and styles out there. You have test driven development, rapid application development, feature driven development and a whole bunch of other types of development approaches you can take.
My favourite approach for personal projects is API Driven Development. You’re probably wondering if it is even a real thing. Before writing this article I wasn’t even sure myself. Sure enough, I found some posts on the subject of API Driven Development proving that I am not crazy and that API Driven Development is a real thing.
What is an API?
API stands for Application Programming Interface. The best way to think about an API is using the example of Microsoft Windows being the API for your PC’s hardware. It handles all of the intricacies of allowing an external system to interact with itself.
What is API Driven Development?
The approach I take is as simple as structuring your data first and then building your applications code around that. The general idea is you define your application data, its structure and everything to do with the data/API side of your application before you write a single line of code.
You work out the flow and data architecture of your application and then write the code to work with the structure you have created. This might be creating a database, its tables and working out how they connect then writing the code to interact with them.
While this might be a weird concept to grasp for my agile, test-driven, prototype loving friends, it actually is quite nice.
Say goodbye to Cowboy Driven Development
You could argue many different development approaches prevent cowboy driven development (writing code without a purpose). Meaning you don’t just slap a whole bunch of code and 3rd party libraries together until things work.
At least with an API and pre-existing data structure, you can mould your application around the type of data you have, not what you will have. API Driven Development is a realistic approach to building an application, like McDonald’s you know what you are going to get before you go through the drive-through.
Would a builder start building a house without the blueprints or concrete slab foundation to build upon? Of course not. So why should software or web development be any different?
Being a developer is really no different to that of a builder, except builders actually do physical work usually out in the sun and us developers sit at our desks sipping $5 organic fair trade hot coffee in an air conditioned office.
The benefits of API Driven Development
The biggest benefit is you don’t waste time, you know what you’re building before you’ve built it. I’ve worked using all kinds of destructive methodologies and no matter how great the process is, things rarely go to plan.
Meaning there is sometimes little to no prior planning, you just build whatever you’re told to build and hope nothing too massive changes as the short deadline hangs above your head. Developing without uncertainty is unproductive and honestly it’s a waste of money.
The general idea of what I believe to be API Driven Development is you lock down your data structure, you’ve created your V1 of your database and its tables. You know what each piece of content is and how it connects to another. You just have to focus on making the UI part work in all required browsers and hand-held devices.
SPA Frameworks
Single Page Application frameworks like AngularJS or EmberJS are made for API Driven Development as they are great static interfaces to traditionally RESTful API’s. The front and back parts are completely separate, with the front-end merely interfacing with the data API.
If you are confident the structure will not change API wise (at least not version 1) you can appropriately model your front-end knowing how things will function with confidence you will only have to write a piece of API interacting functionality once.
Not having to go in and drastically change data models on the front-end because something changed in the back-end is a big plus in my opinion. Focus on the logic and change the data structure later on.
Conclusion
If rapid prototyping and constantly changing your applications structure to keep up with a non-standardised database is not your thing, maybe API Driven Development is something you should try.
It will feel weird at first defining your application structure before you have even built it, but at the same time, think of API Driven Development at the blueprint to your code building.
What do you think about making a prototype using AngularJs/any Other SPA framework first with JSON mocked data(our future API) to understand how UX will be first?
That would definitely fit in with an API Driven Development approach. I have done that in the past, because lets face it, sometimes you don’t always get a completed API first. Mocking the API allows you to make decisions around what your real API will look like and from an application perspective nothing would change except the endpoint where the data will come from when you have a real API.