Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Envoy Mobile

eng.lyft.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: Envoy Mobile

#11

Post by bndw »

SriniK wrote: post #9
polskibus wrote: post #3

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 a…

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. E…

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

Re: Envoy Mobile

#12

Post by wmf »

zubairq wrote: post #6

So does this mean that containers will be able to run on mobile devices?

No, this is a library that is linked in to a mobile app.

Although arguably iOS/Android sandboxing is already akin to a container.

Re: Envoy Mobile

#13

Post by goawaypls »

InTheArena wrote: post #4

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.

While we see a lot of potential in protobuf-based interfaces, rest assured that this is fully-intended to be a general-use networking library. (Lyft employee/project contributor here.)

Re: Envoy Mobile

#14

Post by goawaypls »

simonw wrote: post #5

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.

Thanks, we're excited to be able to do this in the open and welcome community involvement!

Re: Envoy Mobile

#15

Post by graphememes »

SriniK wrote: post #9
polskibus wrote: post #3

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 a…

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. E…

It's an API client.

Re: Envoy Mobile

#17

Post by jonhohle »

jensneuse wrote: post #7

What are possible use cases for a proxy in a client?

I see this more as a "smart" client, where you can push routing, load balancing, retry policy, etc. out to the clients instead of enforcing those at your infrastructure edge… which seems great for controlled clients, but not-feasible for public facing use-cases:

    * routing rules potentially sensitive architectural 
      information and expose many different nodes to the
      public internet
    * a mobile client doesn't generate enough "load" that the 
      typical use case for load balancing would be used for
    * retry & timeout policies seem useful
However, I'm a curmudgeon that doesn't see a huge benefit to a service mesh over a traditional load balancer in the vast majority of applications. Load balancers can offer a lot of the same functionality at scale (thousands of requests per second) and abstract these ideas away from the client, which has more benefit, in my opinion.

I have used smart clients in the past to interface with, what is now being called, a service mesh. For low latency operations that could possibly hit one of thousands of hosts, it worked well… until network fabric changed and hosts were no longer directly accessible. Then operations became increasingly difficult since you had to be on the appropriate network to communicate.

Re: Envoy Mobile

#18

Post by __float »

adamfeldman wrote: post #2

Is there anything similar to Envoy Mobile for browser-based apps?

Unfortunately, browsers don't give very much (if any) control over the networking components -- so you lose out on possibilities for much observability, you can't do things like implement HTTP/2 if your browser doesn't already give it to you, you can't tune DNS stuff at all, etc. Especially as, right now, it only supports gRPC, which requires a proxy on the server side if you want to use gRPC from the browser.

What benefits would you like to see for a browser-based app?

Re: Envoy Mobile

#19

Post by oaktowner »

polskibus wrote: post #3

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 a…

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!

Re: Envoy Mobile

#20

Post by edgetech »

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?
Post reply on HN