API Gateway vs Backend For Frontend

One part of modern microservice systems is the so-called API Gateway. A component sitting on the edge of the network for the system, through which all communication between clients and the system flows. However, there is also the Backend For Frontend (BFF) pattern, which is a variation of the API Gateway pattern. We will talk briefly about the differences between those two patterns and when to use which one.

Common Goals

From a high-level perspective, both patterns follow the same goals. They are decoupling the system's services from the actual clients that use the system. Such decoupling can be useful because if clients would talk directly to each microservice they would need to know about the location of each service and either all services need to support the client's communication protocol or the client would need to support multiple communication protocols offered by different services.

When using an API Gateway clients need only to know about the API Gateway's location, whether the request is served by service A or service B does not matter to the client and therefore there should be no direct coupling between service A and the client.

The API Gateway is then able to handle cross-cutting concerns like Authentication, Rate Limiting and to translate between the client's and the service's communication protocol.

Difference

So far these properties hold true for both API Gateways and BFFs, but how do they differ?

While an API Gateway is a single point of entry into the system for all clients, a BFF is only responsible for a single type of client. Let's assume your system has two (typical) clients: a Single Page Application (SPA) and a mobile client (Android, iOS). In this case, each client would get its own API Gateway, which would therefore be a BFF.

When to use which

When we have to decide whether we want to use the API Gateway or the BFF approach, there are several indicators that can help us to decide between the two approaches.

In case there are several clients we have to ask ourselves:

• How different are the needs of each client? Do we need to support different communication protocols? One client might use GraphQL and the other one REST APIs with JSON.
• Are the clients owned by different teams? In this case it might make sense to use the BFF pattern, because many times we don't want components with shared ownership in a microservice system. Each team could then have full ownership over its own BFF.
• Are we performing aggregation in the API Gateway? Although many off-the-shelve implementations of API Gateways, like Amazons API Gateway and Kong do not support to this functionality, a custom solution might do so. In this case, it's very likely that after time the aggregations will be different for each type of client (think about the different screen-real-estate between mobile and desktop). This would be an additional indicator for us to use an API Gateway.
• Are the clients using different authentication mechanisms? In this case, it might make sense to use BFFs instead of an API Gateway that supports multiple authentication mechanisms that are only used by a single client.
• How similar is the handling of the different clients? Especially when it comes to cross-cutting concerns like the authentication mechanism, rate limiting, and data aggregation if we find that there is a significant overlap between the different clients we need to ask ourselves whether this overlap can be handled on the configuration level of the framework we are using or whether we would need to duplicate code.

Resources

You might also be interested in Microservice Bad Smells - Common Problems in Microservices.

If you want to know more about the API Gateway and Backend For Frontend patterns you should definitely check out the API Gateway page on microservices.io. An even more detailed description of this can be found in the book Microservice Patterns, whose author is also the owner of microservices.io.