4 ms·

If you find yourself doing in-code joins across microservices, you need to stop and think: Are my services correctly scoped? Am I doing these joins because the

If you find yourself doing in-code joins across microservices, you need to stop and think: Are my services correctly scoped? Am I doing these joins because there is maybe a higher level domain that goes across these two services? Should I re-scope my services? Or should I build an Aggregator-View service that holds a JOINED copy of the data. These aggregator-view services often make sense as Backend-For-Frontends. They must be restricted to a read-only API since they mirror data from other microservices. GraphQL is a dead end when you are doing joins in code.

tpetry 6y ago
What you are describing is in my optinion the exact problem happening with almost all microservices. Building an aggregator microservice to join together two services is another microservice in a complex microservice landscape... People on hn seem to hate monoliths, but a monolith with just a few services outsourced to microservices is much easier to handle. No more joining microservice, no more race conditions when trying to do transactional processing over some microservices and all the problems of microservices.
- konschubert 6y ago
  I agree that a well-maintained monolith is simpler and more stable than micro services. The emphasis is on well-maintained. If you’ve ever had team A write a crazy query and kill the database for team B, you’ll start to appreciate the damage containment and encapsulation that microservices provide. EDIT: Of course there might be other, better solutions to this problem.
  - konschubert 6y ago
    With “kill the database” I mean things such as transaction deadlocks.
fatnoah 6y ago
>If you find yourself doing in-code joins across microservices, you need to stop and think: This is a place where far too few people stop to think about what you're doing. I've seen too many cases where an operation requires coordinating requests across multiple service methods THAT ARE ONLY USED IN THAT PARTICULAR OPERATION! The devs spend all of their time a) coordinating things and b) trying to make it performant and c) realizing none of the gains of having microservices to begin with.

tpetry 6y ago

What you are describing is in my optinion the exact problem happening with almost all microservices. Building an aggregator microservice to join together two services is another microservice in a complex microservice landscape... People on hn seem to hate monoliths, but a monolith with just a few services outsourced to microservices is much easier to handle. No more joining microservice, no more race conditions when trying to do transactional processing over some microservices and all the problems of microservices.

konschubert 6y ago
I agree that a well-maintained monolith is simpler and more stable than micro services. The emphasis is on well-maintained. If you’ve ever had team A write a crazy query and kill the database for team B, you’ll start to appreciate the damage containment and encapsulation that microservices provide. EDIT: Of course there might be other, better solutions to this problem.
- konschubert 6y ago
  With “kill the database” I mean things such as transaction deadlocks.

fatnoah 6y ago

>If you find yourself doing in-code joins across microservices, you need to stop and think: This is a place where far too few people stop to think about what you're doing. I've seen too many cases where an operation requires coordinating requests across multiple service methods THAT ARE ONLY USED IN THAT PARTICULAR OPERATION! The devs spend all of their time a) coordinating things and b) trying to make it performant and c) realizing none of the gains of having microservices to begin with.