I think the best solution depends on how the data needs to be merged/aggregated.
Assuming that you have a database that stores EntityA and another database that stores EntityB.
If the data is displayed separately on the front-end
If you display the data of those separately in the front-end then it would be good to have two services, each returning data from a single repository instead of creating a response that contains data from both databases in separate properties.
- The user can see the data immediately when it loads instead of having to wait for all of the data to load before seeing anything.
- Easier to maintain the code because the data is processed in separate controllers/services.
If the data is aggregated (the data has a relationship)
For example you have StatisticA which contains data from both EntityA and EntityB. Then it would be good to have a single service that aggregates the data from two repositories. I do not see any issues when using multiple repositories in a single service.
- Servers are typically more powerful than client machines so the aggregation is faster if there is a lot of data.
- The aggregated data can be cached on server-side so multiple clients do not need to aggregate it.
- Easier to unit test because all of the processing happens on server-side.
- Easier to log errors with the aggregation.
- If the logic is updated then there is no risk that the client has cached the aggregation logic and shows incorrect values.
- If in the future you want to use the statistics for some other purpose (for example send a notification if there is an anomaly) then you can just call the endpoint/service to get the aggregated statistics to check instead of having to somehow reuse the client code or even duplicate it.
- Additional load on the server which can become an issue. Offloading the aggregation to the client would help with this.