December 4, 2024
Agenda
- Demo: Builtin HTTP and messaging
- Demo and Discussion: OTEL - proper trace hierarchy
- Discussion: Feature flags
Meeting Notes
Welcome Márk Kővári, he is full-stack developer interested in getting more closely involved in Wasm. He has an early defined Wasm project created a couple years ago, and has been a boot camp teacher for around 7 years. Márk joins us from Budapest, Hungary. Great to see you, Márk!
Demo: builtin-http
and builtin-messaging
- As always it's difficult to cover the joy of our demos and so please check out the recording below.
- PR landed last week - provider builtins. Just as we have native capability providers, we have been thinking about
builtin-http
andbuiltin-messaging
providers. Instead of spinning out a seperate binary we delegate the listening on an http port or listen to a NATS message going to the wasmCloud host itself. - There are some key differences and some pros and cons and so Brooks takes us through what's new.
- These new devlopments will come in 1.5.
builtin-http
andbuiltin-messaging
are experimental. - Enabling this with Feature Flags - new to the host. We'll cover this later.
- In his demo, Brooks shows how the http server image reference is formed of a special syntax for a wasmCloud 'builtin'. We can use this alongside the same configuration we use for native providers.
- We do the same thing for the messaging contract. Single function
handle message
is received from a message broker. This is initially built in the wasmCloud message interface but we are also designing for WASI messaging. - The biggest benefit is speed and performance - noticeable. Microseconds versus milliseconds. More to come.
- The downside? Building the provider into the host means if we want to ship a new versiom of the http server or a security patch for the http library we need to ship a new version of the host, rather than a new versiom of the plugin. This is worth consideration if you're thinking of taking advantage of this capability. You can opt in now, but we will make these optional and easy to disable.
- Check out the demo and the wider discussion below.
Discussion: Feature flags
builtin-http
andbuiltin-messaging
are the first two examples of where we're using feature flags in new ways.- We wanted to open up the discussion to talk about how we enable/disable new APIs without creating breaking changes. Bailey suggests what we ahbe right now is reat and matches the way we would feature flag with Rust (for instance) but we want to explore what it would look like for an app to expose feature flags and how this might be reflected in a wadm deployment.
- These are simple config changes by any other name. It is often the combination of feature fags which can cause issues.
- There are a few design suggestions we could bring in: K8s feature gates, open features (CNCF), should wasmCloud itself expose feature flags?
- Feature gates: general idea is that new experimental features are generally added behind a feature gate - there is a page with 50-100 feature gates over different releases - as the project matures it goes through an evolution proess - Alpha, Beta, GA etc.
- Scheduling requires Feature Gate specification. As feature matures it progresses from Beta to GA.
- This is a way to experiment with new features without making them a requirement, and invite trials within a protected, gated process. Joonas takes us through how this approach works.
- Flags exposed by apps themselves? Bailey kicks off an interesting discussion as to how this can be done - check out the recording below.
- Jochen: open feature back end - could be a really cool ecosystem to plug into. Github - most folks using this now.
- Component wrapping - Luke Wagner's donut model is another exciting evolution and the focus becomes how can we optimize wasmCloud to capitalize. More soon.
Catch up!
Great news! The WasmCon + KubeCon session playlists are now live on YouTube! There are some fantastic examples of Wasm - and wasmCloud - being used in industry. Perfect viewing for these darker Winter evenings.