DEMO: Update on Go component testing with WAdge - Roman
As always, it's difficult to capture the goodness of Roman's demo so please check out the recording below!
This project changed names from west to WAdge for a couple of reasons. west is already a project name, it has also changed its purpose a little.
WAdge is designed to be a bridge between native code and components.
WAdge lets us access functionality supported by components in your native code. For instance importing native libraries to your component and testing that component.
This is extremely useful for the testing of components as if they are native code running on your system. It allows you to test your component in your own environment with your own tools debug etc.
wasi-http and nothing extra but we can go one level deeper. If we want to use custom providers for specific use cases - this is also supported in WAdge.
Check out the recording to see how it works and listen to the wider discussion.
As above, it's super difficult to capture the goodness of Lachlan's demo so please check out the recording below!
Backstage is an important component of the enterprise toolkit so we're pleased to show progress on our Backstage Plugin, currently in beta.
We have been talking to the community to find out what people are using. Backstage is gaining a lot of traction - it is a CNCF project donated by Spotify - a way to surface all of the different pieces of their platform internally amongst their various teams.
We are focusing first on the software catalog - service interface that shares information about your application, available throughout the platform, so you can see what you already have and reuse it where possible.
Consume and API, build a component and share that amongst disparate teams to be consumed in other parts of the organization.
See status, config, construction, status overview then reconfig, reuse existing software = cost and resource efficiencies.
Upcoming changes to wash build. This started as a way to build components in languages that wasmCloud knows - Rust, TinyGo etc.
One specific aspect will improve - the way we build source code to a Wasm component, this Rust toolchain blog is a good reference point.
As we move forward we have just updated to the latest verson of wash to use Rust's wasm32-wasip1 target, then proceeding with adapting the module to a Wasm component
Once wasm32-wasip2 is included in the stable toolchain (works in nightly today!), we'll update wash to use this directly.
TinyGo components will also compile to the wasip2 target, which means we can use native TinyGo to build directly to a component.
Targeting P2 will be the standard default when you're running wash build.
This way we ensure you're always using the latest and greatest, out of the box with wasmCloud.
wasmCloud Innovation Day was a fantastic event. If you didn't make it, you can catch up on all the sessions in our review post or catch up on the recording on YouTube.