We're using a ton of really new, cool, undocumented, tech stuffs. Personally, I keep ending up in the cycle of.. get blocked, code splunk, "AHA, thats how it works"..

We should get a blog setup so we can start sharing the what we're learning with everyone else. I suspect a big barrier to adoption for wasm right now is just a lack of information.

Summary

We're piping though all the needed components on the backend to expose wasi to guest components (with the exception of wasi threads). However, aside from STDIO none of the wasi features are available to guests as the components are not including the wasi wasm components at compile time.

Note: See here for where we're providing the wasi view and linking them all up.

Task

Bytecode alliance provides the wit-deps library which we can hookup in each guests build.rs https://github.com/bytecodealliance/wit-deps/

Once hooked up in the build.rs script, it will pull in the .wit definitions at compile time so wit-bindgen has access to the descriptors :D

Once setup we should be able to add wit imports to our guest wit definitions

This PR creates the foundation for the mycelia development server.

The development server added in this pr consists of a hyper http server and a tonic grpc backend. For now, the development server supports a hosting a single function. The only command added in this PR is swapping out the running function.

closes #8

Goal

Provide a binary which hosts a http server that provides access to the deployed function and a RPC server for controlling the development server instance. Additionally, a rust client lib should be created to unblock #5

Tasks

• create a hyper instance for the function interface. Forward all calls to the function.
• create a hyper instance for the RPC interface.

Note, originally I was thinking of using Tonic but protobuf.. 😩

Usage:

Available commands inside the workspace:

• cargo run: shows available CLI commands
• cargo run build: builds project using xtask
• cargo run start: starts dev server
• cargo run stop: stops dev server
• cargo run deploy: deploys component to path

Goal

The development server needs access to tooling to easily: Spin up new components, swap out existing components with updated version, pass data to and from components. Thankfully, much of the hard work involved with interfacing with wasmtime has been resolved by wit 🥳 .

Today we have the beginnings of a runtime lib located in the runtime crate (lol). Let's expand on it.

Task

Create a runtime handle which wraps up the process of instantiating new components. For now the key bit of functionality is simply creating a component from a wasm blob. FunctionWorld::instantiate_pre appears to be how we now "pre compile" a module.

Future iterations will need to put some more thought into the context, store, etc. Furthermore, it isn't clear what the best way is to manage the lifecycle of created wasm components.

Motivation

Mycelia is going to need a CLI and it needs to work well with cargo.

There is a package located at /cli with clap already added as a dependency. Documentation on using clap with cargo can be found here. And, there is a ton of examples here.

Task

The CLI will need to support four sub commands.

1. start - start the development server in the current process
2. stop - send an RPC call to the running server requesting a shutdown
3. deploy - send an RPC command requesting the server load a new function wasm
4. build - build the current project for wasm32-wasi and create a component using wasm-tools

Blockers

1. The dev server doesn't exist... @SuddenlyHazel needs to build this.