Add experimental/reference language SDK

[mathetake]

Background

A dynamic module is, by definition, a shared library that implements the Envoy C ABI defined in a single pure C header file. Technically speaking, any programming language that can produce a shared library can be used as a language for Envoy dynamic modules. In fact, in my initial proof of concept work, not only the Rust SDK but I also implemented the Go SDK. The initial motivation was in order to avoid accidentally introducing a language specific ABI, and the obvious choices were Go and Rust, the two most popular programming languages in a modern software.

On the other hand, there's a Golang specific similar extension mechanism in the contrib, so if we have a Go SDK in dynamic module core, it might be confusing to users due to different two Go SDKs present in the repository. That was the reason why we decided not to have Go but instead only Rust in the envoyproxy/envoy repository.

During the KubeCon EU this week, I had a lot of conversation around the other language support, notably Go SDK. There were at least four companies asking for the Go SDK support, and it was obvious that there's a huge community interest around it.

Proposal

Since the ABI is/was designed in a language agnostic way, so there's nothing to prevent someone from writing their own SDKs, just that it requires a bit of expertise etc. That means anyone can publish their own version of SDK in their style on their personal org/account. That is not a good thing in terms of the envoy ecosystem fragmentation, so I propose that we have "experimental SDK" or "reference SDK implementation" here in the examples repository so that multiple companies / community members can work on it and do collaboration to avoid duplicate efforts as well as the ecosystem fragmentation. It can be any language, not limited to Go like Zig, C, C++, maybe even Python or JavaScript with some host implementation here.

Speaking of Go SDK specifically, the ultimate goal would be to migrate the SDK created here to envoyproxy/envoy as a core AFTER we have all the feature parity with golang extension, and we have a migration path. That's going to take a lot of work and time since we need to keep the ABI language agnostic, and especially the design around the asynchronous callbacks requires a serious consideration.

If this sounds good to community members and users, I will kick off the scaffolding of Go reference implementation here, and start migrating the PoC Go SDK implementation.

[fraser-atlassian]

I am one of the conversations that @mathetake mentions, so throwing my 2 cents into the ring.

At Atlassian we have extended Envoy in several ways and we have even created a plugin mechanism for our internal developers to run code on requests and responses. This was implemented via a Go ext proc server running alongside the Envoy but we would love to be able to remove the need for a sidecar but also have more powerful Envoy APIs.

We also have several lua extensions, which benefit from running inside Envoy but its not our preferred language. Having support for a feature rich, stable Go API would mean we can do more.

We would be more willing to use dynamic modules with a supported Go SDK rather than roll our own.

TL;DR: Atlassian would like to see this happen.

[hypnoce]

We are planning to extend envoy for

• OIDC flow extension and session management. This involves the usage of http client as well, either using native golang http client in goroutine or the envoy async http client if exposed via the ABI and implemented in the go sdk. Also need to access the Secret Manager.
• specific header logs formatting. This filter is really simple and the current ABI is sufficient.

As we build envoy internally and keep the version in sync with the go code, we do not need ABI stability. So the current go sdk provides everything we need.

Nevertheless, from a community perspective, It would be good to have a convergence between the current go SDK and dynamic_module initiative, especially that @mathetake POCed a go sdk skeleton for dynamic_modules. Since a big part of the work is in the ABI and C++ implementation of the ABI, having a common ground for all language is a big plus.

[mathetake]

cool thank you folks for explaining real use cases - I will kick off the scaffolding within this week !

[mathetake]

@hypnoce @fraser-atlassian I landed the scaffolding PR #26 - I will work on one additional PR soon but feel free to contribute to it as well as play with it!

[mathetake]

ok after #27, I would like helps from you and other community members to polish the Go SDK as well as add more integration tests!