Problem

Configuration is currently accepted as a string in Envoy Mobile, and the demo apps read from a YAML file and pipe the information through. This approach has a few downsides:

• Makes configurations difficult to validate at build time
• Causes runtime errors when starting Envoy with invalid configurations due to the fact that Envoy Mobile only ships with a subset of the configurations available from upstream Envoy
• Steep learning curve for learning how to set up Envoy configurations
• It's not immediately clear to new users which Envoy configurations are available within Envoy Mobile and which aren't, and these aren't enforced

Proposal

Create typed configuration models that may be instantiated at runtime and passed to Envoy Mobile when starting new instances.

A few approaches are available here:

a) Provide strong types from the Envoy Mobile libraries which the user can specify when starting up Envoy. The native layer can then translate these to JSON which Envoy can already understand. This is lightweight since we can use native types without having to depend on external libraries (like protobuf)

b) Utilize the protobuf models that upstream Envoy uses for configuration. This can be problematic since not all these configurations are supported on Envoy Mobile (we'd still have to validate them at runtime), and it would require dependencies on protobuf libraries

We currently have a strong preference for option a. In addition to the above, we can also provide an "advanced" initializer that continues to accept a raw YAML/JSON string which the user can load from a file and use to instantiate Envoy.

Work

Assuming we go with option a above:

• Define the native models to expose publicly for configurations
• Define a basic set of configuration that ships enabled with Envoy Mobile by default. This can then be mutated by the end consumer prior to starting the library (similar to URLSessionConfiguration)
• Ensure that the timeouts set in the demos by configs: slow down certain refreshes #218 are also reflected under the hood in these typed configurations
• Add tests for converting these models to supported JSON configurations
• Support a builder pattern for creating configurations in order to make them as user-friendly as possible

Google doc section: Link