To Optimize APIs, Loosen Up

Bill Appleton, CEO, DreamFactory Software

content-image
Businesses today are under tremendous pressure to keep producing new mobile applications. Operationally, when a mobile application is developed, there is usually a server-side team that builds the application program interface (API) and a client-side team that builds the application. Two distinct development teams and their interaction are defined by the API interface they are building.

The interaction between these two groups takes lots of time and money while they converge on an interface. In fact, Gartner estimates that 75 percent of the cost of a mobile project is related to backend integration. This black hole of time and cost can be countered by loosely coupled API architecture that minimizes the interaction between these two teams.

At the center of this problem is the common practice of developing a new API for every new project. This approach leads to backend complexity, and over time, a company can end up with infrastructure that is not portable, scalable, reliable, or secure. I believe that companies should never develop an API for any specific application. It is a road to trouble that too many projects take.

The unfortunate side effect of the starting from scratch on APIs for each new project approach is that most mobile applications end up being tightly coupled to the API services that they use.

I believe that companies should never develop an API for any specific application

Each server-side API is often developed for a specific mobile application project. Each new custom application then requires another special-purpose API. In other words, the application and the service end up being tightly coupled to one another.

In the same manner, if your server-side team is deeply engaged with your client-side team, then they are tightly coupled as well. These two teams can end up spending lots of time playing an expensive game of API ping-pong instead of actually shipping new applications.

In software engineering, a tightly coupled design means that components tend to be interdependent. Changes in a single component can have a system wide impact, with unanticipated and undesirable effects. That is why the concept of loose coupling is incredibly important. In a loosely coupled design, components are independent, and changes in one will not affect the operation of others. This approach offers optimal flexibility and reusability when components are added, replaced, or modified.

When the concept of loose coupling is applied to building APIs, they can be used and reused in a flexible manner for general-purpose application development. The advantages are enormous. For example, developers do not need to learn a new API to develop a new application. The same APIs can be reused for many different purposes. The total number of services and endpoints is consolidated, improving security. Documentation, user roles, and API services become standardized, enhancing corporate governance and compliance.

The server-side team focuses on mobilizing data sources, connecting legacy services, and administering role based security for the platform. The front-end team then builds anything they want on their platform of choice. Problems are minimized because the developers automatically receive the services that they need.

Embracing loosely coupled design is a tangible and efficient path to minimize the black hole of time and cost in development and accelerate productivity in the API economy.

Weekly Brief