In the previous article, we've learned how to setup an API gateway using ASP.net Core and Ocelot. This article supplements the previous article by introducing downstream response aggregation through the use of API gateways. You can download the application used in this article by cloning it from GITHUB.

Articles in the Series

Recap

This article belongs to a series of articles that explains the importance of API gateways and how to build them using ASP.net Core. If you're interested to learn more about API gateways, it might be a good idea to spend some time reading the articles listed below.

In the previous article, we've setup a simple API gateway that aggregates three bounded context APIs (Authentication, Ledger and Catalog). This gateway merely behaves like a reverse-proxy and does nothing special, which is totally fine with simple API gateway use-cases. However, API gateways become more interesting when they start performing response aggregation.

Response Aggregation

Response aggregation is a technique used for merging response from multiple downstream services into a single object. API gateways achieve this by accepting a single request from clients and issuing multiple parallelized requests to downstream services, once all downstream services responds, API gateways perform merging of data into single object and serves it to the clients. This technique results to the following benefits:

Fewer HTTP transactions between client and server Since the responsibility of sending requests to multiple downstream services is offloaded to the API gateway, the communication between the client is reduced to a fewer transaction.

Since the responsibility of sending requests to multiple downstream services is offloaded to the API gateway, the communication between the client is reduced to a fewer transaction. Client only needs to know a single schema. Since API gateways aggregate response objects, client-parties only need to deal with a single form of data as compared to dealing schema from multiple providers.

Since API gateways aggregate response objects, client-parties only need to deal with a single form of data as compared to dealing schema from multiple providers. Cross continental communication become faster. If the invoking client resides on a different geo-location, the latency factor introduced by cross-continental communication becomes lesser.

Request Aggregation Demo

In order to showcase response aggregation, we will setup an endpoint that will accept a single client request which will then be propagated to our ledger and authentication service for the retrieval of user's profile and all the transactions he/she is involved with.

User Profile Endpoint

User Transactions Endpoint

Basic JSON Response Aggregation

Ocelot offers a powerful mechanism for performing simple response aggregation from downstream services that serve data in JSON format. This could be achieved by writing similar mappings from the previous article but this time with a key property. The key property helps ocelot identify which downstream endpoints to aggregate when configuring an aggregated upstream endpoint.

User Profile Endpoint Mapping

User Transactions Endpoint Mapping

Aggregated Route Configuration

You can test the output of the individual endpoint re-routes and aggregated route using the links below:

User Profile

http://localhost:52793/api/user/getbyid/539bf338-e5de-4fc4-ac65-4a91324d8111

User Transactions

http://localhost:52793/api/transaction/getbyuserid/539bf338-e5de-4fc4-ac65-4a91324d8111

User Profile + Transactions

http://localhost:52793/api/user-transactions/539bf338-e5de-4fc4-ac65-4a91324d8111

Result

Conclusion

Ocelot offers a simple yet powerful mechanism to aggregate multiple downstream endpoints. This feature eases the life of front-end developers that previously have to deal with multiple endpoints. In the next article we will explore how to use Rate Limiting to defend our API gateways from DDOS attacks.

Related Articles

Get Some Cool Stuff From Amazon!