4 ms·
Personally I always prefer Microservices and some sort of CI pipeline over a classic Monolith. Yes, it's painful sometimes but when using some best practices (e
by blablabla123 5y ago
Personally I always prefer Microservices and some sort of CI pipeline over a classic Monolith. Yes, it's painful sometimes but when using some best practices (e.g. one DB per service) it works surprisingly well and can offer benefits that monoliths just can't. But I think it's fair to write Monoliths for new projects - many people do.
- Daishiman 5y agoI cannot possibly understand why you would do that. You're dropping the ability to do trivial joins, trivial reporting, trivial SQL aggregates, over... what, exactly?
- procinct 5y agoGenerally I believe it's done for encapsulation between teams. That way, each team can own their code without any fear of another team being able to break anything provided they all work to their contracts. If you can perform a join to get the data yourself, nothing is stopping anyone from circumventing your API that is intended for fetching the data or by making breaking changes to the single database that your code relies on. But yes, trivial joins is effectively the trade off for this encapsulation and can mean other services have to collect their own versions of data from services which means you now have eventual consistency.