Skip to content

Deploying to Sandbox

The project Designer generates carries its own scripts to build its components and publish them. Once they’re published, any client can run your commands and read your State Views.

  • Fill in the todo!() in each decide stub.
  • Fill in the // TODO arms in each evolve stub. An unfilled evolve still compiles, and returns empty state.
  • If a State View folds events from more than one stream, widen the selector in its metadata.json; see Generating code.
  • Complete the test scaffolds, which are ignored until you do, and run them:
Terminal window
cargo test -- --ignored
Terminal window
./build_all.sh

This compiles every State Change and State View to a WebAssembly component under target/wasm32-wasip2/release/.

The Sandbox:

Terminal window
export EVIDENTSOURCE_URL=https://sandbox.evidentsource.com

Your machine, with the project’s docker-compose.yml, which runs EvidentSource in memory and its MCP server:

Terminal window
docker compose up -d
export EVIDENTSOURCE_URL=http://localhost:3000

install.sh publishes to a database named after your model, unless you set EVIDENTSOURCE_DATABASE, and creates it if it doesn’t exist. On the shared Sandbox, choose a name no one else is likely to use:

Terminal window
export EVIDENTSOURCE_DATABASE=my-model-yourname
Terminal window
./install.sh --all

Answer y to the prompt. ./install.sh --list shows the components, and ./install.sh state-change <name> publishes one.

Publish a changed component again, and it becomes the next version: the first is v1, the next v2. Publishing exactly what the latest active version holds, the same module and the same metadata, returns that version instead, so a retried publish adds nothing unless another publish landed in between. Earlier versions stay published, and a caller names the version it wants in the route, so moving back is a matter of calling the earlier version. Nothing in the event log changes.