Another role we can give to a gateway is aggregating requests to hide complexity from its consumers. Aggregating multiple requests into one makes it easier for consumers of a microservices system to interact with it; clients need to know about one endpoint instead of multiple. Moreover, it moves the chattiness from the client to the gateway, which is closer to the microservices, lowering the many calls’ latency, and thus making the request-response cycle faster.Continuing with our previous example, we have two UI applications that contain a feature to show a device’s location on a map before identifying it using its name/model. To achieve this, they must call the device twin endpoint to obtain the device’s name and model and the location endpoint to get its last known location. So, two requests to display a small box times two UIs means four requests to maintain a simple feature. If we extrapolate, we could end up managing a huge number of HTTP requests for a handful of features.Here is a diagram showing our feature in its current state:
Figure 19.19: A web application and a mobile app that are calling two microservices through a gateway application
To remedy this problem, we can apply the Gateway Aggregation pattern to simplify our UIs and offload the responsibility of managing those details to the gateway.By applying the Gateway Aggregation pattern, we end up with the following simplified flow:
Figure 19.20: A gateway that aggregates the response of two requests to serve a single request from both a web application and a mobile app
In the previous flow, the Web App calls the Gateway that calls the two APIs, then crafts a response combining the two responses it got from the APIs. The Gateway then returns that response to the Web App. With that in place, the Web App is loosely coupled with the two APIs while the Gateway plays the intermediary. With only one HTTP request, the Web App has all the information it needs, aggregated by the Gateway.Next, let’s explore the steps that occurred. The following diagram shows that the Web App makes a single request (1) while the gateway makes two calls (2 and 4). In the diagram, the requests are sent in series, but we could have sent them in parallel to speed things up:
Figure 19.21: The order in which the requests take place
Like the routing gateway, an aggregation gateway can become the bottleneck of your application and a single point of failure, so beware of that.Another important point is the latency between the gateway and the internal APIs. The clients will wait for every response if the latency is too high. So, deploying the gateway close to the microservices it interacts with could become crucial for system performance. The gateway can also implement caching to improve performance further and make subsequent requests faster.Next, we explore another type of gateway that creates specialized gateways instead of generic ones.
