The API Middle-End

If a frontend provides a user interface, a backend handles the logic and accesses the data, what does a middle-end do?

Most people are against adding logic to an API gateway. The reason is that adding logic introduces latency to a layer that should handle API requests as quickly as possible. While I admire this reason, I don't agree with it. I believe we can now fix latency in a cost-effective way. You probably understand by now that what I see as the API middle-end is an enhanced version of the gateway. What are then its responsibilities, and what do the frontend and backend do? Read on.

---

This article is brought to you with the help of our supporter: Speakeasy.

Speakeasy provides you with the tools to craft truly developer-friendly integration experiences for your APIs: idiomatic, strongly typed, lightweight & customizable SDKs in 8+ languages, Terraform providers & always-in-sync docs. Increase API user adoption with friction-free integrations.

---

In the world of Web applications, frontend and backend are elements anyone can understand. Users access a Web application and interact with it through its frontend. Then, the frontend communicates with the backend—whenever needed—to retrieve information and perform operations. A Web frontend is also responsible for creating and delivering the visual elements of the Web application. Especially with Single Page Applications (SPAs), the communication between the frontend and the backend happens on-demand, without the explicit knowledge of the end-user. But there are more things that we can attribute to the frontend layer of a Web application.

The distribution of content and assets is one area that's usually overlooked. However, it's crucial that users can easily access both your content and assets, such as images, CSS files, and scripts. Using a content delivery network (CDN) is something that can be attributed to the frontend layer. CDNs make content and assets available at the lowest possible latency, independently of users' geography. You can see a CDN as the "last mile" during the delivery of your Web application to end users. CDNs use a number of techniques to increase the availability of content. Among those techniques, the most popular ones are caching and storing copies of the content geographically close to where end users are located—this is what is often called edge.

You can also apply this notion of frontend to an API. The processes that make an API available at a low latency to any consumer can be seen as its frontend. After all, the frontend is the thin interface layer that separates users from what the API provides. I'd include in that layer anything related to access, including authentication and rate limiting. The API frontend guarantees that users can access the API and that they have the correct authorization to perform the requested operation. At that point, the API frontend passes the request to another layer that attempts to execute the logic necessary to fulfill the requirement.

To me, an API middle-end is responsible for all the logic related to the interface. It's in charge of getting the information from the backend and passing it to the frontend. You can use this layer to add automation and translation logic. This layer can, for instance, translate responses from the backend so they all adhere to a consistent convention. Or, it can automatically add elements to response payloads, such as links to other related objects—following the HATEOAS approach. Anything that's related to manipulating request parameters, the input body, and the response payload can belong in the API middle-end.

A scenario where an API middle-end exists is beneficial to both the producer and the consumers. API producers can, in an expedited fashion, add logic to adapt requests and responses to what consumers need. On top of that, consumers will be able to use an API that's fully adapted to them. Perhaps, just perhaps, there can even be multiple instances of the same API, each one adapted to a specific use case. And the best place to have this middle-end running is the API gateway. It's naturally positioned in between the API distribution—the frontend—and the backend business logic. The only challenge is the latency that all the transformation logic can add.

Let's see how we can mitigate the middle-end latency. We can split it into the CPU-bound and network-bound categories. The first type of latency has to do with the processing that's needed to translate request and response payloads in between protocols and formats. Most of this translation has to do with processing data. One way to mitigate this latency is to do vertical scaling, increasing the processing power of each instance where the middle-end is running. The network-bound latency is not so easy to mitigate. It happens whenever the middle-end needs to compose the responses from different backend APIs together to create a new response. Each request it makes to a backend API introduces latency. Ways to mitigate this latency involve adding a cache whenever possible, making backend operations asynchronous whenever appropriate, and avoiding large payloads.

It's not impossible to add an API middle-end. The latency challenge is not an excuse for not having the benefits of on-demand API translation and composition. In fact, some APIs are already following this approach. GraphQL APIs, for instance, have the ability to use "stitching" as a way to group together the response of several APIs. It's a matter of time before API producers see the middle-end as a viable component.

---