3 ms·
The main problem with fat clients is that for polyglot architectures (which most large companies that end up building a service mesh evolve into over time) you
by omeze 7y ago
The main problem with fat clients is that for polyglot architectures (which most large companies that end up building a service mesh evolve into over time) you have to maintain a fat client library for every language. You can get very far leveraging existing tools like gRPC that codegens fatty clients for you but the quality of tooling is very uneven depending on the language of choice. By pushing all of this into the network layer you skip all of that.
- theamk 7y agoRight, polyglot architectures have no choice, but this text talks about “5 person startups” as well. Surely they can keep the set of languages limited? Plus, it’s not either/or situation. A fat clients for Go + Node.js; and a proxy for all others. This way your core logic can enjoy increased introspection / more speed / higher reliability; while special purpose services get a proxy which allow interoperability.