Imagine this scenario. You and the company you work for built an awesome web application for a client which has been in use for almost 6 months. One day the client pays a visit and says that due to the popular demands from his customers, he wants you to develop a desktop and mobile client for it. The web app your company built though was a tightly coupled, server-side rendered MVC application. Whoopsies!
This is a very common and precarious situation most companies encounter more often than not. This is because of the rapid advancement of technology as well as the unpredictability of customer requirements. The most common solution that companies in this situation usually go for is by building a separate API for the existing application which usually brings about redundancy as well as doubling the amount and effort to build and maintain.
Granted, there may be situations where you have no choice. For instance, the app may have already been built using that architecture before you assumed control of it. In such cases, this solution works best. If you are building the application from scratch though, it might be wise to use API-First approach so as not to encounter the scenario described.
What then, is API-First approach?
It is an approach to building device agnostic software where API's act as the base interface to the entire application. In other words, API's are treated as first-class citizens and essentially become the only way to communicate and access data from the application. Anything not exposed by the API is practically non-existent to the developers building on top of it.
The most popular types of API's include but not limited to:
- SOAP - Simple Object Access Protocol
- REST - Representational State Transfer
- RPC's - Remote Procedure Calls
- GraphQL
Since API's only deal with data, they bring about flexibility because front-end developers are at liberty to display the data to the user any way they like. For example, the profile page in a mobile app client may be displayed differently to that on the desktop client even though they consume the same data. The data may be of the following data exchange formats:
- XML - Extensible Markup Language
- JSON - JavaScript Object Notation
- Protobuf - Protocol Buffers
Benefits of API-First Approach
- Reduces code redundancy
- Promotes separation of concerns
- Easier to extend
- Brings about interoperability as multiple client apps consume the same data.
- Easier to maintain
- Easier to test and debug
- Brings about flexibility
- Encourages the use of microservices architecture
Since customer demands are highly unpredictable, using an API-First Approach might be your best bet as it usually does and will pay dividends in the future, saving you time, efforts and headaches.
Happy coding!
Top comments (2)
I do not think this term should exists, I mean its name is misleading. The API is not at the core of the app design, the entities and actions are the ones who dictates the API structure and properties. You cannot invent an API and after than think at your business logic. The *DD techniques are all about this, the API is just an artifact.
Never the less, it is a normal evolution of the classical 3-layer architecture and I think that you are crazy if you do not build your new systems using this technique.
Another thing, I do not like is that you are stealing all the traits of the APIs and attribute it to this technique. Most of the benefits you mention came from the fact that you have an API, not that you used ADD. Same goes as TDD, your code is not better from the TDD is just that you have unit tests.
PS: you forgot about GraphQL which is a major player nowdays
Yeah, the title was misleading. Updated it.
Thanks.