I really like how they're releasing this as effectively the first working proof of concept and committing to developing the rest entirely in the open - it's a great opportunity to see how a project of this scale plays out in real-time on GitHub.
So envoy will now provide a client-side library? Is there a particular reason why such client-side enhancements should not be applied to all Api clients, not just on mobile?<p>What is the ultimate goal here? Reduce the amount of boilerplate required to handle all possible edge cases when communicating with a remote service, like need to retry, etc?<p>I'd like to understand the value prop from a perspective of a generic api client, that does not now if there is Envoy, or any other load balancer on the other end.
I've been waiting to see this for a while, because this is intrinsically about extending the service mesh to end devices. Unfortunately it does seem to be more protobuf / gRPC specific then I would like at the moment, but device connectivity is absolutely something that should be managed as a separate concern from core application development.
Really interested in cases where people have taken xDS to user-scale. Presumably you would want to implement the Delta Discovery Service to minimize the bandwidth used by xDS updates, however, then you're maintaining state on the xDS server which adds server overhead.<p>We're adopting xDS as an abstraction for our service discovery. Implementing it has been relatively straightforward even with the relatively minimal documentation outside of the hints provided by the Envoy specific configuration elements.
The hello-world example (At least in Objective-C) shows a 'run-envoy' call followed by the client code making requests to envoy in the same process over HTTP on a dedicated port. Will there be a client API or is the model that one uses a local HTTP client to speak to your in-process envoy?
Shout out to Lyft for Envoy. I haven't used it all that much, but it's been very set and forget. The other "API gateways" like Linkerd and Kong are either a bunch of hacky Lua scripts (Kong) or use a lot of ram for the number of instances you'll probably want (Linkerd)