Microservice Aggregator Service BFF

These Microservices patterns always come with Trade-offs. Here you need to consider more than just a coupling issue when you are going with Aggregator pattern (Backend for Frontend).

The following are some of the points you need to think about before going with this pattern.

1. The Latency problem. If you want this implementation to make it better without any latency problem, then your services and aggregator should be in the same location or the same data center. Avoid third party calls from aggregators.
2. This can introduce a single point of failure. Make sure that you've designed in such a way that the service is highly available.
3. Implement a resilient design and timeout since this aggregator is calling other services and getting data. If one or more service calls take too long, it should timeout and return a partial set of data. Consider how your application will handle this scenario
4. Monitoring of your aggregator and it's child service calls. Implement distributed tracing using correlation IDs to track each call.
5. Ensure the aggregator has the adequate performance to handle the load and can be scaled to meet your anticipated growth.

These are the best practices that I can suggest, You are the best person who can decide based on your system requirements and these points.

There are some compelling advantages to using a BfF service as an orchestration layer that aggregates calls to various backend data services.

1. It will reduce the complexity in the data access areas of your SPA.
2. It can also reduce load times.
3. Over time, your frontend devs will be less likely to get blocked on the backend devs assuming that the BfF is maintained by the frontend devs.

Take a look at this article on Consistency, Coupling, and Complexity at the Edge that goes into more detail on this and proposes some best practices such as GraphQL vs REST.