Typically in a microservice architecture, the granularity of APIs provided by individual microservices is often different than what a client needs. Also the set of microservices changes frequently. In such a scenario, clients don't want an overhead of coordinating and processing/consolidating API responses from multiple services. Also, modern applications have multiple user interfaces, with different requirements and network performances. For example, a desktop client (including a browser) will typically show a richer interface and have access to a stable network connection. On the other hand, mobile applications have limited screen real estate and also have to deal with slower/more finicky mobile networks.

The API gateway pattern provides a solution for this, by implementing a single entry point for all the backend services. At the least, it performs routing of specific URLs to a backend service, and provides common features such as authentication, throttling, and so on.

Some may also implement complex features such as aggregation (call multiple services and compose a consolidated response).

The pattern is depicted here:

One problem that people saw with a single point of API aggregation is that different clients often have very different interaction models. The general-purpose API gateway becomes an anti-pattern, as there is no segregation of concerns. It also leads to development bottlenecks for rolling out new features, as now rollouts have to coordinate with this central team, and as all changes are made to the same artifact.

One solution to this problem is to have one API gateway for each frontend—what is called the Backend For Frontend (BFF) pattern. Each BFF is specific to a client (user experience) and will typically be maintained by the same team as the client. Thus you get both of the following advantages:

• A lot of the heavy lifting in terms of API calling and aggregation moves to the backend as in the API gateway pattern.
• There is no coupling of concerns in one monolithic code base.

The pattern is illustrated as follows:

As you can see, there is often a shared library to host common code with only the client/UI specifics being different in each BFF service.

Sometimes, an aggregation can be very complex and have lots of use cases. In such a case, it's best to factor out a separate aggregation service. In our travel website example, search would be such a use case. In this case, the architecture would look as follows: