Envoy Mobile & the upcoming networking revolution

Talk given at Swiftable in Buenos Aires, Argentina in November 2019.

Transcript

1. Envoy Mobile & the upcoming networking revolution Michael Rebello @rebello95 Swiftable (Buenos Aires) - November 2019
2. Service Networking Networking iOS
3. Service Flask, etc. URLSession iOS
4. Service Library X Library X iOS
5. Service Envoy Envoy Mobile iOS
6. Let’s talk about what data we send, then come back to how we send it.
7. Early API workflow at Lyft Tech spec handwritten.swift handwritten.kt handwritten.py/.go
8. let params: [String: Any] = [ "lat": position.latitude, "lng": position.longitude, "some_param": true, ] client.request(.post, "/foo", parameters: params) { result in … } Early APIs at Lyft
9. • Handwritten code led to mistakes/typos Problems
10. iOS Server { “key_a”: “hello” } Programming errors
11. iOS Server { “key_a”: “hello” } Android { “kye_a”: “hello” } Programming errors
12. iOS Server { “key_a”: “hello” } Android { “kye_a”: “hello” } if (android): else: Programming errors
13. • Handwritten code led to mistakes/typos • No visibility into deserialization failures Problems
14. import Mapper extension FooResponse: Mappable { init(map: Mapper) throws { self.placeID = try map.from("place_id") let item: String? = map.optionalFrom("items") self.placeDisplay = map.optionalFrom("display.lien_two") } } Deserialization failures
15. import Mapper extension FooResponse: Mappable { init(map: Mapper) throws { self.placeID = try map.from("place_id") let item: String? = map.optionalFrom("items") self.placeDisplay = map.optionalFrom("display.lien_two") } } Deserialization failures
16. import Mapper extension FooResponse: Mappable { init(map: Mapper) throws { self.placeID = try map.from("place_id") let item: String? = map.optionalFrom("items") self.placeDisplay = map.optionalFrom("display.lien_two") } } Deserialization failures
17. • Handwritten code led to mistakes/typos • No visibility into deserialization failures • No single source of truth Problems
18. YAML integration
19. paths: /foo: post: parameters: - in: body schema: $ref: '#/definitions/FooRequest' responses: 200: schema: $ref: '#/definitions/FooResponse' YAML definitions
20. • Manual code generation for Android • No integration on iOS or services • Still inconsistencies across platforms • No single source of truth YAML results
21. Consistency
22. We needed a source of truth that provided guarantees for the behavior of any given API.
23. IDL & protobuf
24. Interface Definition Language IDL
25. Old workflow Tech spec handwritten.swift handwritten.kt handwritten.py/.go
26. Envisioned workflow Tech spec IDL repo foo_api.swift foo_api.kt foo_api.py/.go foo_api.proto
27. Platform-neutral IDL for defining and serializing APIs. Protocol buffers (“protobufs”)
28. • Simple to write • Open-source generators available for most popular languages • JSON support • Optimized wire encoding Why protobuf?
29. Intro to protobuf
30. message FooRequest { … } message FooResponse { int64 id = 1; string first_name = 2; } service Foo { rpc UpdateFoo(FooRequest) returns (FooResponse) { option (http.http_options).path = "/foo"; option (http.http_options).method = "POST"; } } Protobuf definition
31. message FooRequest { … } message FooResponse { int64 id = 1; string first_name = 2; } service Foo { rpc UpdateFoo(FooRequest) returns (FooResponse) { option (http.http_options).path = "/foo"; option (http.http_options).method = "POST"; } } Protobuf messages
32. message FooRequest { … } message FooResponse { int64 id = 1; string first_name = 2; } service Foo { rpc UpdateFoo(FooRequest) returns (FooResponse) { option (http.http_options).path = "/foo"; option (http.http_options).method = "POST"; } } Protobuf fields
33. message FooRequest { … } message FooResponse { int64 id = 1; string first_name = 2; } service Foo { rpc UpdateFoo(FooRequest) returns (FooResponse) { option (http.http_options).path = "/foo"; option (http.http_options).method = "POST"; } } Protobuf services
34. message FooRequest { … } message FooResponse { int64 id = 1; string first_name = 2; } service Foo { rpc UpdateFoo(FooRequest) returns (FooResponse) { option (http.http_options).path = "/foo"; option (http.http_options).method = "POST"; } } Protobuf RPCs (Remote Procedure Calls)
35. message FooRequest { … } message FooResponse { int64 id = 1; string first_name = 2; } service Foo { rpc UpdateFoo(FooRequest) returns (FooResponse) { option (http.http_options).path = "/foo"; option (http.http_options).method = "POST"; } } Protobuf annotations
36. IDL pipeline /api/foo.proto Generators +7 others foo.go foo.py foo.kt foo.swift
37. IDL pipeline /api/foo.proto Generators +7 others foo.go foo.py foo.kt foo.swift FooV1API library foo-v1-api library
38. Using protobuf in Swift
39. // Modules/FooV1API/FooAPI.swift public struct FooRequest: Codable, Equatable { … } public struct FooResponse: Codable, Equatable { public let id: Int64 public let firstName: String } Generated models
40. // Modules/FooV1API/FooAPI.swift import RxSwift public protocol FooAPI { func updateFoo(_ request: FooRequest) -> Single<Result<FooResponse, FooAPIError>> } public struct FooClientAPI: FooAPI { // Abstracted implementation } Generated APIs
41. // Modules/FooV1API/FooAPI.swift import RxSwift public protocol FooAPI { func updateFoo(_ request: FooRequest) -> Single<Result<FooResponse, FooAPIError>> } public struct FooClientAPI: FooAPI { // Abstracted implementation } Generated APIs
42. // Modules/FooV1APIMock/FooAPI.swift open class FooMockAPI: FooAPI { open lazy var mockUpdateFoo: (FooRequest) -> Result<FooResponse, FooAPIError> = { … } open func updateFoo(_ request: FooRequest) -> Single<Result<FooResponse, FooAPIError>> { … } } Generated mocks
43. // Modules/FooFeatureModule/FooFeature.swift getFooClientAPI() .updateFoo(FooRequest(...)) .subscribe({ result in switch result { case .success(let response): // Consume the response case .failure(let error): // Handle the failure } }) .disposed(by: self.disposeBag) Using APIs
44. ★ Single source of truth for all APIs ★ Consistent interfaces across platforms ★ Ergonomic generated code on all platforms ★ Highly testable ★ Wire format fully abstracted Results
45. Optimizing transport: Content negotiation
46. Client Service JSON request Existing system JSON response
47. Client Service JSON request Content-Type: json Accept: x-protobuf,json Content negotiation Middleware (service) JSON > Protobuf Protobuf request Content-Type: x-protobuf Protobuf response Content-Type: x-protobuf Middleware (service) No change Protobuf response Content-Type: x-protobuf
48. JSON Protobuf
49. • 40%+ reduction in payload sizes • Faster response times • Higher success rates • Transparent to engineers Wins from protobuf
50. What if we want to change how we send data rather than what we send?
51. C++ proxy that abstracts networking from services
52. Envoy service mesh Service A Proxy Service B Proxy HTTP/1.1, HTTP/2, gRPC, etc. HTTP/1.1, HTTP/2, gRPC, etc.
53. Envoy filters Common functionality executed on each request or response
54. Envoy filters Service A Filter Add auth headers Filter gzip request Proxy Proxy Filter Unzip payload Filter Validate auth headers Service B
55. Envoy service mesh + front proxy Service A Proxy Service B Proxy HTTP/1.1, HTTP/2, gRPC, etc. Client Proxy
56. Service Library X Library X iOS
58. Service A Proxy Service B Proxy Proxy Client Mobile
59. • 1 network stack for all platforms • Write filter functionality once, deploy everywhere • Support new protocols like HTTP/3 (QUIC) • Consistent stats/monitoring across all platforms Envoy Mobile!
60. Stats Real-time requests from Envoy Mobile on Lyft rider (alpha)
61. Envoy Mobile will revolutionize how we enable network consistency across all platforms.
62. envoy-mobile.github.io @rebello95 Join us!