I wanna share some information about a pattern that is particularly interesting when you have an infrastructure composed of an API Gateway, some backend services (such as when working with a Microservices architecture) and a set of Frontend application consumers.
Intent
This pattern addresses those situations when a Request Aggregation is required but it is not possible to tackle it with an API Gateway or other means.
Sometimes, even though the API Gateway may provide Request Aggregation capabilities, it does not fit our application needs or expectations, hence some custom code is necessary to fulfill our requirements. Also, it might be required some level of flexibility that is not provided by those out of the box features in tools like API Gateways.
Motivation
Having a Backend – Frontend architecture composed by several microservices or independent services in the Backend, the Frontend application must be unaware of the implementation details in the Backend. Also, in case the Backend services change in any way, the Frontend should not be affected whatsoever.
Therefore, there must be a mechanism in place for those situations when a Frontend application requests a set of data that is split over different microservices in the Backend (e.g. header and details invoice), but that it appears as one only service / call from the Frontend perspective.
Primary View
Element Catalog
| Element | Functional description |
|---|---|
| Frontend App | Those sets of applications consumed by end users. This includes, but it is not limited to: Mobile and Web Applications. |
| API Gateway | API Gateway that acts as a reverse proxy. It provides a good set of functionalities such as: load balancing, authentication and authorization, protocol transformation, IP whitelisting and much more. |
| Aggregator | The main component of this pattern. This contains the logic to aggregate the required data from the different microservices or service independent units, to encapsulate the whole complexity of the backend services to the frontend applications. |
| Service | The microservice or service independent unit that provides specific functionality for the application. |
Consecuences
The aggregator pattern provides a way to aggregate requests when interaction with different services in the backend is needed. This encapsulates the complexity in the backend and keeps the frontend application agnostic about the implementation details in the back. It provides a lot of flexibility, as you can create specific code that may address your business needs. Nonetheless, it is not for free. This pattern requires the management of an additional piece of software that must be maintained and evolve with its own lifecycle. That said, it can be scaled depending on the needs and avoid changes on the frontend application consumers when the backend changes need to be modified in any way.
Vicluar Daniel Merchan 