Backend or Frontend who owns the API orchestration layer?

Writing API’s representing data models is always fun, it represents the abstract design thought of the developer. A scalable and performant API design requires a lot of analysis and system understanding.

#Microservice architecture becomes very popular because it simplifies the process of API creation and maintenance. It scales well as a single unit.

Microservices though solve the problems of a single unit but adds more complexity in maintaining the relationships among services. This becomes more visible when different teams consume these Apis.

Let's understand this with an example.

At housing.com when a builder uploads a listing image, we find out the image tag (bedroom, bathroom, hall, etc) using machine learning.

In a #monolithic architecture, it is a simple image upload request which returns the image tag in response and does all the magic in the background.

But in a microservice architecture, there can be two services one for handling image uploads and related optimizations and another for doing all the machine learning stuff.

Now client needs to make two requests first to upload an image and then to get tags using some image identifier returned from the first request. This is suboptimal, it adds unnecessary latency and exposes internal details to the client.

This can be solved in two ways.

1. Using the API orchestrations layer

2. Using macroservices (well-sized services) something explored by Uber and a few other companies.

In this article, I will discuss only point 1 i.e API orchestration layer.

What is an API orchestration layer?

API orchestration layer is an abstraction layer that collects data from one or more services and prepares them in favor of client applications.

In the above example, it is an extra layer between the client and 2 microservices. The client makes an image upload request to the API orchestration layer which communicates with the two microservices and returns the image tags.

This solves the latency issues as the API orchestration layer and microservices can be part of the same network(virtual private cloud). Exposing internal details is also resolved as all communication is happening through the new API orchestration layer.

Who is the consumer of the API orchestration layer?

There can be many consumers of the API orchestration layer based on your organization's objectives. Some of the most common consumers in organizations are.

1. Web Application
2. Mobile Application
3. Microservices
4. Internal tools and panels
5. Third-Party integrations

now we come to the most important question

Who owns the API orchestration layer?

We have three choices for ownership.

1. Backend
2. Frontend (Client)
3. Both

Let's explore the benefits and issues with all three approaches.

API orchestration layer owned by Backend Systems

The #backend has always been an ideal candidate for the API orchestration layer. Many organizations prefer to keep ownership of this layer on the backend because of the following reasons.

Upsides

1. Understanding of data model and performance pitfalls of internal services are very well known at the backend. This knowledge is very trivial to optimize things at the orchestration layer.

Example — Writing a fallback logic in case if some service gets down.

2. Not always true but in general people working at backend systems have better knowledge of caching systems, fault tolerance, etc. which are primary elements of the API orchestration layer.

3. Writing an individual API orchestration layer for each client will lead to a lot of duplicated effort.

4. Third-party issues can only be resolved if this layer is part of the backend system. They have no reason to write an orchestration layer for the integration.

5. Handling security and hiding the internal details of APIs cannot be part of a team that does not own the internals.

Backend though looks like an ideal place for the API orchestration layer but it has its downsides too.

Downsides

One critical job of the API orchestration layer is to prepare responses in the client’s expected way. If there are ten clients then creating a custom response for each is a tough job. In some cases clients may need to make frequent changes and creating dependency upon the backend system will only lead to delay and chaos.

Now check what will happen if we shift this responsibility to #frontend applications.

API orchestration layer owned by Frontend Systems

Modern frontend applications have started taking this responsibility to some extent. This is because of the popularity and overwhelming response to GraphQL in the front-end community.

Upsides

1. Backend is only responsible for maintaining the purity of the data model.

2. UI-related parsing and modification are now under the client’s ownership and this is a major win as it can reduce frontend dev time.

3. Scope of more client-centric optimizations increased like persistent queries if using #GraphQL. The client can modify the layer as per its need. which is not possible if the layer is owned by the backend. The backend needs to support multiple clients and optimizing for one client may not be ideal if it does not work for other clients.

Downsides

1. Duplicate effort from different clients.

2. Security and internal details are not guaranteed to be maintained.

3. Third parties still have to compromise on performance and implementation.

4. Cache invalidation and maintenance will remain a major challenge.

GraphQL has added a new chapter in how API orchestration layers were written. The only problem is its adoption is weak on the backend side. Only in very few organizations backend teams are using GraphQL.

Since both have their upsides and downsides can we use both to reduce the problem areas?

API orchestration layer owned by both Frontend and Backend Systems

Using both will help mitigate some of the above issues but will introduce some new issues.

The backend owned API orchestration layer will be responsible for security, third parties, and common requirements among different clients.

Frontend owned API orchestration layer will be responsible for data parsing in the desired format, frontend specific performance optimizations, etc.

Upsides

1. Backend expertise is very well utilized for caching, fault tolerance, security, etc.

2. Backend and frontend dependency for UI tweaks is resolved as it is now owned by the frontend itself.

3. Frontend is free to perform any front-end related optimization.

4. Third parties are now under the backend API orchestration layer.

Downsides

1. There is no clear distinction between what is owned by the frontend system and what is owned by the backend system.

2. Duplicate effort may still be there.

3. One more extra layer means one more hop. Latency will surely increase.

None of these is the best option. All have one or the other issue. I am interested in more discussion on this and reach a solution that really works.

Please share your thoughts and ideas in the comments.

For more on web performance please check my Personal Website