Use the right approach for building a data back end

The interaction between front-end apps and their back end can be developed using different approaches, which don’t impact agility in the same way

building a wall
Public Domain

The modern client app (which can be a mobile app, a website, a specialized device, or even a UI-less connected object) feeds from a data and/or service backend. The approach you use to design and develop the front end, the back end, and the exchanges between the two, matters more than you may think. It has a huge impact on agility -- not only of the infrastructure, but also of the business as a whole.

Interactions between front end and back end are essentially driven by Web APIs. Therefore, API design strategy drives the entire application infrastructure strategy. Let’s look at the most commonly used strategies.

Development-driven strategy

The development-driven approach is derived from traditional n-tier stack models. It is comprised of sequential phases:

  1. Development of the back-end services.
  2. Creation of the API that exposes access to these back-end services.
  3. Production of client SDKs to call this API.
  4. Development of the front-end clients, using the SDKs provided.

In this mode, the responsibility of each part of the stack clearly lies with a distinct development team, and the entire process is well structured and organized.

However, because of the dependency that each team has on the previous step (i.e., the front-end team cannot develop the client apps until SDKs are available, SDKs cannot be produced before the API is created), this approach can also impair agility and slow down progress.

Design-driven strategy

With the design-driven approach, some of the development tasks can be parallelized, right after the API is defined -- and before it is actually implemented. The process is as follows:

  1. Definition of the API, through the creation of what is called an API contract that defines the services that can be called, and the format of the data sets that will be returned.
  2. Production of client SDKs to call this API.
  3. Development of an API mock -- simply put, a strawman implementation of the API, without any business logic, but that will return properly formatted responses to each call. This API mock is the key to been able to test the front-end clients.
  4. Simultaneous development of the front-end clients and back-end services. These back-end services, in certain cases, can be wired to the API in substitution of the API mock once they are completed.

The drawback of this mode is that more work needs to go into the definition of the API and the development of the API mock, than when using the development-driven strategy.

However, the parallelization of development tasks that ensues (back end and front end can progress at the same time) typically saves a lot of time and shortens the time to market of the completed application infrastructure.

There is also an induced benefit to the design-driven strategy: It typically entails less back and forth between front-end and back-end teams. The creation of the API contract is often a collaborative effort, or at least it happens earlier in the development cycle. And the API mock lets front-end developers perform realistic tests of their apps against the API before the actual back end has been developed. For these two reasons, requests for changes that front-end developers can come up with are usually less impactful since they are addressed earlier in the development cycle.

This article is published as part of the IDG Contributor Network. Want to Join?