If we structure the configuration in swift we are opening up the gates for having to do the same in every language we want to support.

I outlined some of the concerns with a purely string-based approach in the linked issue, but to add some more color:

• Envoy Mobile supports a small subset of the configurations that are available in upstream Envoy. This will likely always be the case, and going outside those configurations can cause undefined behavior at runtime. Using types can help alleviate this
• Having consumers manually load configuration file resources and pass them to Envoy Mobile at runtime is additional overhead and can lead to bugs discovered at runtime instead of build time (invalid config files, mis-loading resources, etc.)
• Envoy's current configurations are non-trivial and require a learning curve to be able to use them at all. The status quo of networking libraries on mobile generally requires little up-front configuration cost, and we should try to match that here to encourage wider adoption
• Supporting this in each language (currently Swift/Kotlin) does amount to some overhead, but that can be said about every other aspect of the library as well (i.e., Envoy Mobile isn't all C++ 😄)

What are your thoughts about maintenance of this typed configuration approach?

• Configs will be forwards compatible. Using a builder pattern on both platforms will allow us to add new defaults without making consumers update their code unless they want to take advantage of the new features
• On the other hand, we can always deprecate/remove options from the configuration if necessary (especially pre-1.0), and consumers will find out at build time rather than when loading a config file at runtime

In summary: I think the reduced barrier to entry, ease of use, and simplicity of typed configurations far out-weighs the minimal maintenance cost this will incur.

Thanks for that explanation. It goes to show my bias from the far more complex land of service mesh configurations. I think all the reasons listed above really assuage any immediate concerns I have with this approach :)

Envoy's current configurations are non-trivial and require a learning curve to be able to use them at all. The status quo of networking libraries on mobile generally requires little up-front configuration cost, and we should try to match that here to encourage wider adoption.

This specially makes me agree with the approach taken here. And reminds me that a very similar pattern is being used in cronet; with, as you say here, a very small configuration surface.

I talked with @junr03 a bit about this offline. In general, while I think @junr03's concerns merit consideration, I tend to agree with @rebello95's points above. To summarize a couple of the things we discussed:

I think the challenges the Network Team has faced are a bit beyond the scope of what we'll encounter here. The configuration of Lyft's mesh is far more complex than our default template configuration will ever have to be.

The proto generation, serialization and deserialization that would be required to support the proto based approach is a fair amount of overhead, whereas string interpolation is cheap, and at least for a smaller set of configurable touch points, easy.

Finally, I think we can avoid the risks of implementing across languages by having the templating be well-documented. If this ends up being a pain point, we can also consider migrating templating logic down into the common layer at some point down the road.

Finally, I think we can avoid the risks of implementing across languages by having the templating be well-documented. If this ends up being a pain point, we can also consider migrating templating logic down into the common layer at some point down the road.

Yep I think documenting this is very valuable, and we can also use upstream Envoy's comprehensive docs as a point of reference here too. I also think it's useful to allow consumers to instantiate Envoy Mobile instances using raw string files (which is maintained in this PR), for those who are interested in doing something ultra-customized.

Implementation looks great; just a couple minor suggestions.