Microservices Patterns: API Gateway and BFF Patterns

Miroservices Patterns Series — Part 08

API Gateway Pattern

API Gateway Pattern: Implementing a service that is the entry point into a microservices based application from external API clients. [1]

Due to a lot of drawbacks with clients trying to access microservices directly via the Internet, it is recommended to apply the API Gateway pattern as a solution and a design pattern. It basically works as the entry point into a microservices application from the outside your system boundary.

This pattern is quite similar to the Facade Pattern in object orientation, which encapsulates the microservices application internal architecture and provides and API to its clients.

Figure 01 — API Gateway Advantage

Some of the key responsibilities of the API Gateway Pattern are as follows:

1. Request Routing
2. API Composition
3. Edge Functions
4. Protocol Transformations

Out of four (04) responsibilities mentioned, both request routing and API compositions are the main key features of any API Gateway.

The third option, which is the Edge function can be helpful to utilize one of the following.

1 Authentication — Verifying the client identity

2. Authorization — Verifying the client is authorized to perform a particular API operation

3. Rate limiting — Limiting the incoming requests from clients

4. Caching — Caching the responses to reduce the number of incoming requests to the back-end service.

5 Matrix Collection — Collecting metrics on API usage

6. Request logging — Logging client requests

All these edge operations can be implemented at three different levels in your deployment architecture.

1. Back-end services level — [Less secure]
2. Edge service level — [This is to have a separate service layer for an Edge service. This is better than the first option, but requires an additional hop]
3. API Gateway level — [This requires less hops than the the second option and it is more secure and convenient to govern]

However, generally the API Gateway governance is taken care of by a separate API Gateway team and not by other individual API teams. This situation will definitely lead to governance conflicts.

Therefore, it is always good to separate the API Gateway governance by having separate API Gateway for each API / microservices team. This approach is known as Backends for Frontends (BFF) pattern.

Backends for Frontends (BFF) Pattern

BFF Pattern: Implement a separate API Gateway for each type of client.[1]

Figure 02 — Without BFF

Figure 03 — With BFF

As you see on figure 02, there is a common API Gateway for all types of clients and on figure 03, there are separate API Gateways (micro) for all types of clients.

By having micro API Gateways for each client type, basically isolate the business logic at the API Gateway level for each client type based on certain API logic variations. This allows the reliability for each client type, just as you experience in a typical microservices back-ends.

As a live example, Netflix uses multiple API Gateways for its each client type to improve its scalability and performance.

Implementing an API Gateway

You can take multiple approaches for this.

1. Use a built-in API Gateway cloud based products in the market (AWS API Gateway, etc)
2. Use an Open Source built products (i.e. WSO2 API Gateway, Kong, Traefik, etc)
3. Building your own API Gateway using some existing open source frameworks such as Netflix Zuul or Spring Cloud Gateway. Out of these two, Spring Cloud Gateway is an API Gateway framework built on top of several frameworks such as Spring 5, Spring Boot 2, Spring Webflux and Project Reactor.

References

1. API Gateway Pattern: https://microservices.io/patterns/apigateway.html