We are currently working on migration of an old monolithic desktop application. We've discussed a lot and we decided microservices is the way to go. At the moment we are separating a big part of the old application and for that we clearly identified two microservices. And, in order to avoid frontend from knowing each microservice separatedly, we are building a BFF that will take care of aggregating data and call each microservice needed.
For one case I need to fill a grid that shows some kind of summarized data. This data comes mainly by data owned by Microservice A and is completed with data from microservice B.
What Microservice A is currently doing is executing the specific SQL query to obtain the data with all Counts, Sums, etc needed. Then this is called by BFF which also calls Microservice B to complete the missing data.
Is it that bad to let Microservice A know about specific logic that is needed by frontend?
We discussed this and some disagree and says this logic shouldn't be in Microservice A and instead BFF should be who perform all the calculations needed to return the data to frontend.
I personally agree in some point but I don't see a clear way to solve it. One option is to let Microservice A only returns a huge collection of results so the BFF takes care, of group, count, sum, etc.
Is it that bad to let a microservice have specific logic for a grid or should it be BFF responsability?
I tried to explain as simple as possible but I know it could be a mess to read anyway. Please let me know any doubt you might have.
Thanks
The problem of drawing service boundaries is probably the most difficult one when applying the microservices architectural style. There is no general right answer to the problem as you describe it in an abstract fashion with A and B. The decisions may come down to an experience based case-by-case decision.
In order to give at least some guidance on how to approach this decision - Ask yourself the following questions:
Microservices are often cut in size to be maintained by a two-pizza size team. So what is the organizational impact of locating the aggregation logic you require in either A, B, a new service C, the frontend or aggregation inside an API gateway?
Microservice scope is often set to represent a single business function. So from a business perspective is your aggregation logic closer to the business function of A or B or separate?
Can you achieve to set up the service boundary as to follow the golden rule of loose coupling and strong cohesion?
Is there a need to scale the new logic up and down separately from A and B? In other words will a separate deployment be required?
Do you benefit from separate development / release cycles for the new logic, e.g. due to anticipated changes in the future?
Do you need separate security concerns / rules for the new logic? A separate endpoint can be protected differently.
Is your new logic just aggregation or also state change and if yes, is it of a transactional nature and cannot be allowed to roll back / -partially?
I also recommend you read the this excellent article about how to approach breaking monoliths. Furthermore be aware of the tradeoffs.
(And if you would describe the details of your decision problem here, including domain and logic details I could give my opinion- But know that stack-overflow is not the best place for opinion based question-answers)