Hacker News Reader

Comment by polskibus | Hacker News Reader

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?

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?

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.

View on HN

You can think it as a cross platform networking library.

From the post.

"Low-level networking improvements like HTTP/2, QUIC, QUIC to TCP failover, gRPC, DNS replacements, push/streaming, observability, analytics, state of the art TLS, retry and timeout policies, etc. take a tremendous amount of effort both to implement robustly as well as to make consistent across all of the Android and iOS versions in common use. Envoy Mobile will provide all of this functionality in a consistent cross-platform manner, especially when paired with Envoy running at the edge, similar to how server-side Envoy provides consistency to polyglot distributed application architectures."

Yeah I think the idea is, envoy helps a lot on the server side, but the client side uses almost the exact same algorithms, so we ought to have something like envoy on the client side too.

Put another way-- it extends the service mesh to mobile clients.

It's an API client.

Consider that, on mobile, you're required to use the Android SDK or iOS SDK (or something that effectively "compiles" down to it). You can't use a sidecar app like Envoy Proxy.

On servers and desktops, applications can be built with any language and any framework. To support all of that with a library would be an expensive task that would effectively never be finished. Sure, you could pick the N most-popular languages/frameworks to support, but even that list will be moving target over time. A sidecar proxy there makes a lot more sense, and can work with any language or framework, at the expense of a bit of tighter integration.

I think of Envoy as both a client side and server side proxy.

Typically (in the past) both client and server have been VMs or containers.

Client side it can do things like automatic retries, routing decisions and fault injection (among others). It's super useful.

What this adds is the ability to deploy it as a client in more places...a couple of billion more places!

Reply on news.ycombinator.com