This is my favorite quote from this article &quot;building services that “actually do something” is a recommended practice&quot;. This is an argument I make all the time at work when a team wants to create microservices to serve very specific data types so you can get, put, delete data about a Person, and Organization, or whatever.<p>The service endpoints are easy to define, easy to test, clean and simple... and nearly useless to expose to the frontend. Congrats - you&#x27;ve exposed the database over HTTP. The layer doesn&#x27;t accomplish anything, so it&#x27;s pointless. To my mind, every layer should _do something_ or it should be removed.<p>The end result in some cases has been creating microservices that clients can theoretically build upon, but the orchestration of them is super complex because the services are too data-specific rather than workflow-specific. To do something, a frontend has to make 6 calls just to gather data before it is even ready to present a page of UI.<p>I&#x27;m not making an argument against microservices, just the architecture of exposing data in tiny self-contained (self-absorbed?) chunks. Microservices can expose data that people may want in those tiny pieces, but they should be wrapped up together by other services to aggregate related data to expose to consumers that need to care about workflow. So build a Person service, Organization service, Blog Post service, whatever. But present a Context service that returns large collected pieces.