Edition 0 Updated to asp. Net core 0

The Gateway aggregation pattern in eShopOnContainers 
As introduced previously, a flexible way to implement requests aggregation is with custom services, by 
code. You could also implement request aggregation with the 
Request Aggregation feature in Ocelot
, 
but it might not be as flexible as you need. Therefore, the selected way to implement aggregation in 
eShopOnContainers is with an explicit ASP.NET Core Web API service for each aggregator. 
According to that approach, the API Gateway composition diagram is in reality a bit more extended 
when considering the aggregator services that are not shown in the simplified global architecture 
diagram shown previously. 
In the following diagram, you can also see how the aggregator services work with their related API 
Gateways. 
Figure 6-37. eShopOnContainers architecture with aggregator services 
Zooming in further, on the “Shopping” business area in the following image, you can see that 
chattiness between the client apps and the microservices is reduced when using the aggregator 
services in the API Gateways. 

---

176 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Figure 6-38. Zoom in vision of the Aggregator services 
You can notice how when the diagram shows the possible requests coming from the API Gateways it 
can get complex. On the other hand, when you use the aggregator pattern, you can see how the 
arrows in blue would simplify the communication from a client app perspective. This pattern not only 
helps to reduce the chattiness and latency in the communication, it also improves the user experience 
significantly for the remote apps (mobile and SPA apps). 
In the case of the “Marketing” business area and microservices, it is a simple use case so there was no 
need to use aggregators, but it could also be possible, if needed.