As an increasing number of microservices and their APIs are added to the architecture, a “Problem of Plenty” arises. As in the case of our previous example, the user wanting to know a list of eligible offers for him, it does not constitute a single API call – response. This is rather an instance of a multi- API call – response, involving more than one microservice. In reality, each client therefore will have their own needs for data searching and filtering on different fields they want.
However, the REST APIs of the microservices are unidimensional as they ought to be (per basic thumb rules of MS architecture), and only provide single version of the entity. The onus of navigating through various microservices’ endpoints, co-relating the data, and building the desired data of choice, therefore, falls into the client/front end arena. This is not a desirable situation as the touch points between the front end and back end (microservices) can become too high, increasing the level of chattiness. Here, we must remember that the enhanced network latencies induced by each call ends up dragging down overall performance – a scenario that we stridently try to avoid.
The answer to this problem lies in API aggregation. In our example, it is desirable for the user to call a single aggregated API to obtain their eligible offers. To address this conundrum, here are the three most popular methods for API aggregation based on my experience: