In this post, I will describe six reasons why you, and your company should adopt an API first approach. And why they are critical to your company’s future.
Note, this post is converted from my YouTube video script. And if you want to watch the original video then see below.
In this post, I will describe six reasons why you, and your company should adopt an API first approach. And why they are critical to your company’s future.
What is an API, and how they enable automation and scalability (one & two)
First, let’s run through a straightforward example of ordering a pizza to explain APIs.
A few years back, if you wanted a pizza, you would phone up the pizza place and order a pizza. Yes, you would have picked up a phone and spoke to someone.
Over the phone, you would tell the person on the other end of the phone, your address, and the pizza you would like. And the person would then confirm back with the price and time for delivery.
Suppose more than one person was trying to order if the pizza place only had one person taking orders. Then people would need to wait until an order taker became available to have their order taken. Or more order takers would be required to be free, which is an expense for establishment.
Nowadays, you can use the pizza place’s website or use an application like Just Eat to perform the same telephone order you would have placed, which is made possible with APIs.
And because APIs don’t require a human to take an order, the pizza place can simultaneously receive multiple orders without having people available.
Let’s take a moment to understand two impacts on the pizza place now we have replaced the telephone order process with an Order system exposing an API.
The first benefit is that using an API, communication, and integration between the pizza place and the customer is quicker.
The second is that the need for humans to take the order is removed, leading to automation and the ability to scale.
Which means The pizza place can now receive 100s of pizza orders in the time it took for one telephone order.
And APIs now allow integration and quicker integration between services and third parties.
Quicker integration between services and third parties. (three)
There is a reason why one of the richest men in the world, Mr Jeff B of Amazon famously sent an internal memo to Amazon’s employees stating that all services must expose API’s and communicate using APIs.
And why Banks have embraced Open Banking APIs and standards.
And Why Uber, Netflix, AWS and Stripe have all been so successful, because they put APIs first, because they know that having APIs allows them to be competitive.
Why?
Because a good API allows your applications and third parties; business partners and customers to integrate quickly with your system.
And What is quickly you might be asking?
Well, Google Apigee has the 3 5’s rule, which states that any developer, irreverent of their skill level, should understand what an API does in 5 seconds.
And In 5 minutes They should be able to make a successful request and get a valid response back.
And they should be able to be in production in 5 days or sooner (The 555 rule, Apigee).
Now I don’t know about you, but going from an idea to production in Five days for integration is quick. That timeframe can give a company a competitive advantage in its industry.
Now compare the second part of the 555 rule, making a successful operation in 5 minutes or less. Anyone reading this, who has integrated with another system by dropping files, can relate that it is unrealistic to generate a file in the correct file structure and deliver it to another system via a protocol like SFTP 5 minutes. Usually, this can take hours, if not a couple of days, depending on the developer’s level of experience.
APIs Speed up integration between services and enable you to deliver functionality quicker, promoting reusability and reducing duplication.
Reusability and reduces duplication (four)
And how do they reduce duplication, well in the developing world there are three ways to reuse code.
One. You can Copy and paste code. And then try and maintain the different codebases, making changes when and where it is required and trying to ensure that each service is updated around the same time.
Two. Create shareable class libraries which Sound amazing, but not when you find a critical defect or need to make changes. Like copy and paste, you need to manage the updates and changes for different services across multiple teams when you make changes to the library.
And if you need to upgrade to the library to a newer framework version. It is not normally straight forward to upgrade the services’ framework, so you may even need to maintain different versions of a library simultaneously.
I am not a great fan of shareable class libraries. I also believe that keeping one maintained can take a more significant toll on development in the long than copy and paste.
You may have to ensure that the services are updated at the same time. And trying to manage the changes and updates to production environments for multiple services across multiple teams can be quite a headache.
And option Three, my favourite. Create an API function, which you can call from any service, or client, with a couple of lines of code.
When you need to modify logic, you only need to update one service, compared to updating all services, as long as you are not introducing a breaking change to the contract between the clients and API.
One change to the API service is a lot easier to manage.
Quite simply APIs become the building blocks which you can reuse in your architecture.
Enables quicker innovations and changes (five)
APIs Also enable quicker innovations and changes.
Think back a few years to when we didn’t have client-side frameworks like Angular or React or before jquery, yes that far back.
You would have used a framework that used page load, server postbacks for loading data, and form submissions.
You would have developed a monolithic application where the client and server code was tightly coupled. To test the application, you would have had to build the application, run it, test it manually, or invest in expensive UI automation.
And if you wanted to create another application, or rewrite it in a different framework or version, because the UI and the business logic were tightly coupled, you would need to start from scratch.
If you embrace an API first approach, you can develop different client applications, like web applications, mobile apps separately, and have those other applications using the same APIs without reinventing the wheel.
Some people will say that having an API decouples the client from the API; it doesn’t matter because what happens if the API is down, The client won’t be able to Query data or update data. But it decouples the APIs from the client, but not the other way around.
It enables you to break apart functionality into separate services, smaller services, microservices, or even cell-based functions. Which can be developed, tested, deployed and scaled independently from each other, which reduces the risk that you will break functionality in another service.
Breaking functionality into separate services can Increase time to market, increase development cadence, and development teams can work in parallel.
Once you have APIs that power your UI clients, you can quickly develop the ability to have partners and customers to build integration with your system, increasing your competitiveness and customer satisfaction. Because your existing APIs will act as the building blocks
Reduce database table sharing and increase business innovation and centralising of functionality (six)
Adopting an API first approach can reduce database table sharing and increase business innovation and centralising of functionality.
What do I mean by table sharing, well let’s say you have one table which holds data which multiple services require, without APIs you would have to have all the services reading and possibly writing to the table. Now if you need to change the table, you may need to modify all the services and ensure they are updated together at the same time as the database.
But suppose you enforce that all services that need to access a particular table or set of tables use a specific API. In that case, you are free to make changes to the database table without affecting the clients, which lowers the risk of introducing breaking changes.
Breaking out functionality into specific APIs enables the ability to have specific services to retrieve and manage different objects, reducing database table sharing, allowing companies to innovate and change quickly. Also lowering the risk that you will break other services when deploying changes.
Wrapping up
So in this post, We have run through how APIs allow you to
- Automate business functionality
- Scale business functionality
- Integrate quicker with systems and third parties
- Reduce duplication and promote reusability of existing functions
- Enables companies to innovate, change and be competitive by getting ideas to market quicker
- Lowers the risk of introducing breaking changes, by reducing database table sharing by developing and exposing dedicated APIs for accessing and modifying different database objects
