Edition 0 Updated to asp. Net core 0

Cross-cutting concerns
: Each publicly published microservice must handle concerns such as 
authorization and SSL. In many situations, those concerns could be handled in a single tier so the 
internal microservices are simplified. 
What is the API Gateway pattern? 
When you design and build large or complex microservice-based applications with multiple client 
apps, a good approach to consider can be an 
API Gateway
. This pattern is a service that provides a 
single-
entry point for certain groups of microservices. It’s similar to the 
Facade pattern
 from object-
oriented d
esign, but in this case, it’s part of a distributed system. The API Gateway pattern is also 
sometimes known as the “backend for frontend” (
BFF
) because you build it while thinking about the 
needs of the client app. 
Therefore, the API gateway sits between the client apps and the microservices. It acts as a reverse 
proxy, routing requests from clients to services. It can also provide other cross-cutting features such 
as authentication, SSL termination, and cache. 
Figure 4-13 shows how a custom API Gateway can fit into a simplified microservice-based architecture 
with just a few microservices. 

---

43 
CHAPTER 3 | Architecting container and microservice-based applications 
Figure 4-13. Using an API Gateway implemented as a custom service 
A
pps connect to a single endpoint, the API Gateway, that’s configured to forward requests to 
individual microservices. In this example, the API Gateway would be implemented as a custom 
ASP.NET Core WebHost service running as a container. 
It’s important to h
ighlight that in that diagram, you would be using a single custom API Gateway 
service facing multiple and different client apps. That fact can be an important risk because your API 
Gateway service will be growing and evolving based on many different requirements from the client 
apps. Eventually, it will be bloated because of those different needs and effectively it could be similar 
to a monolithic application or monolithic service. That’s why it’s very much recommended to split the 
API Gateway in multiple services or multiple smaller API Gateways, one per client app form-factor 
type, for instance. 
You need to be careful when implementing the API Gateway pattern. Usually it isn’t a good idea to 
have a single API Gateway aggregating all the internal microservices of your application. If it does, it 
acts as a monolithic aggregator or orchestrator and violates microservice autonomy by coupling all 
the microservices. 
Therefore, the API Gateways should be segregated based on business boundaries and the client apps 
and not act as a single aggregator for all the internal microservices. 
When splitting the API Gateway tier into multiple API Gateways, if your application has multiple client 
apps, that can be a primary pivot when identifying the multiple API Gateways types, so that you can 
have a different facade for the needs of each client app. This case is a pattern named “Backend for 
Frontend” (
BFF
) where each API Gateway can provide a different API tailored for each client app type, 
possibly even based on the client form factor by implementing specific adapter code which 
underneath calls multiple internal microservices, as shown in the following image: 

---

44 
CHAPTER 3 | Architecting container and microservice-based applications 
Figure 4-13.1. Using multiple custom API Gateways 
Figure 4-13.1 shows API Gateways that are segregated by client type; one for mobile clients and one 
for web clients. A traditional web app connects to an MVC microservice that uses the web API 
Gateway. The example depicts a simplified architecture with multiple fine-grained API Gateways. In 
this case, the boundaries identified for each API Gateway are based purely on the “Backend for 
Frontend” (
BFF
) pattern, hence based just on the API needed per client app. But in larger applications 
you should also go further and create other API Gateways based on business boundaries as a second 
design pivot.