Is it okay to have one Service with two different Repositories in Spring Boot MVC?

Question

I have a backend Spring Boot API that should have one(?) endpoint that returns some statistics to display in a frontend. These statistics are calculated from data that comes from two different databases.

Now since I'm using Spring Boot, I understand that each Controller should have a Service and each Service should have one Repository. How bad would it be to have a service with two repositories, that merges the data from them? Would it be better to have two different controllers with their respective services and repositories and then aggregate the results on the front-end side after calling these two endpoints?

What other alternatives do I have for this scenario?

Answer 1

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.

Advantages:

• 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.

Advantages:

• 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.

Disadvantages:

• Additional load on the server which can become an issue. Offloading the aggregation to the client would help with this.