Next Generation Client APIs in Envoy Mobile

What is the work that you're doing today?

Michael: We are working on the Envoy mobile project, which is the subject of our talk as well. It's a client networking library. It's the baseline definition of what it is, but it's also a rethinking of how clients can interact with back-end services. I think a lot of us are probably familiar with the service mesh now, and the idea that you can have a distributed set of instances that represent different services that all communicate with each other. And that's becoming a more common paradigm for back-end systems. But traditionally we've thought of mobile clients as outside of that and have a strong delineation between the back-end and the client. Envoy Mobile rethinks that paradigm and works to bring a lot of the benefits we realized from having a back-end service mesh built on common infrastructure and Enjoy being the basis. With Envoy Mobile we have the same technology stack run everywhere. Envoy Mobile works to bring all the benefits that Envoy and similar technologies have realized on the back-end out to mobile clients as well. In addition to also just being a network library.

What's the goal of your presentation?

Jose: If I can start for this one, the goal of this talk is two fold. First, we want to talk about what shape of data that we're sending and how this has evolved for client APIs at Lyft. And then after that, we lead into how that evolution led to the culmination of rethinking the transport layer and introducing Envoy Mobile as this new concept of how we are going to transport our APIs. 

What do you think would be the ideal attendee persona?

Michael: This is a technically focused talk so definitely oriented more so towards engineers. We do talk about some of infrastructural operational issues as well. But I'd say the talk is geared both towards mobile engineers as well as back-end engineers.

What are some of the actionable takeaways?

Michael: I guess at a high level, a big one is that we feel that for a while now in the industry, we've been all dealing with a very similar set of problems. API evolution is a big one. Moving from the idea of making HTTP calls to REST to model based APIs, strongly typed APIs that pass standardised data back and forth between services as well as functioning in conditions where things will fail. Expected interactions across API will fail. There is a growing feeling we have that we're continuing to encounter these problems. And there's not a good single solution which works to address them or at least provide a foundation for addressing them. And this project aims to provide a solution.