Backend For Frontend Pattern

In this blog post, we will discuss Backend for Frontend pattern. To be honest, I was a bit surprised and skeptical when I first heard about this pattern, but the more I thought about it, the more sense it made. So what exactly is the Backend For Frontend pattern.

The Problem

Consider a generic backend Web Api that interacts with a set of microservices to provide required information to a web client. The solution seems to be working perfectly. At this point, the developers decided to bring out a mobile client. It used the same generic backend Web Api as the desktop client. However, this approach has a hidden flow.

Mobile clients are limited by a lot of constraints, especially screen real estate. One cannot expect to show as much data as in the mobile client as in the web client on one screen. The screen real estate is pretty limited and hence the data displayed in the mobile client has to be specifically filtered/altered.

If the mobile client is forced to use the same generic background, it would need to do additional processing at the client end to display the needed information. This would add additional overhead on the client, which is already limited by processing power compared to desktop clients.

This is the exact problem the Backend For Frontend pattern aims to address. The pattern argues to use a different backend for each of the available front-end client types. This would ensure that the clients are provided with accurate and specific information which it could display. The specific backend would be internally accessing the same set of microservices for retrieving information, but it does the processing internally before passing the required information to the client.

This would also ensure that the backend team would not be in a state of conflict if the generic backend is used and conflicting requests arrive from different frontend developing teams. The backend team(s), each of them working for a specific frontend platform would now be more focused and could fine-tune the performance/data for the specific frontend.

In some of the cases as noted by Sam Newman in his famous article, the backend of the mobile platform is further divided into specific OS platforms. This would further increase the chances of code duplication, but considering the benefits of the approach, that could be a smaller cost. But having said that, the Backend For Frontend Pattern is not a one-stop solution to all the problems and should not be the default solution each time you develop applications that target multiple clients.

In fact, you need to first evaluate each of the requirements of the different clients and then consider how different are the requirements. If there is a considerable difference between the different clients, then the pattern could be considered as a solution. But if the requirement of the different clients isn’t quite prominent, then a generic backend could reduce the development cost by a significant amount.