“Wait, What? Our Microservices Have Human Users?” Stefan Tilkov at MicroXchg(infoq.com)
infoq.com
“Wait, What? Our Microservices Have Human Users?” Stefan Tilkov at MicroXchg
http://www.infoq.com/news/2016/02/tilkov-microxchg-human-users
1 comments
I agree - I'm seeing some application frameworks even encouraging developers to expose CRUD functionality via REST (Spring Data REST, I'm looking at you)
There may be a few narrow use cases where this is valid, but in general we really should avoid doing SQL joins over HTTP :-)
As Stefan argues in the talk, one of the original sins with SOA was caring too much about the services (and potential "reuse"), and forgetting about the notion of offering a cohesive piece of business functionality i.e. a bounded context with well-defined responsibilities
There may be a few narrow use cases where this is valid, but in general we really should avoid doing SQL joins over HTTP :-)
As Stefan argues in the talk, one of the original sins with SOA was caring too much about the services (and potential "reuse"), and forgetting about the notion of offering a cohesive piece of business functionality i.e. a bounded context with well-defined responsibilities
The service endpoints are easy to define, easy to test, clean and simple... and nearly useless to expose to the frontend. Congrats - you've exposed the database over HTTP. The layer doesn't accomplish anything, so it's pointless. To my mind, every layer should _do something_ or it should be removed.
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.
I'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.