In this section: Hands-On Examples
- Chapter 4 Feature Flag Evaluator Tutorial
- Chapter 5 Post Fetcher Runtime Tutorial
- Chapter 6 Universal Microservices Architecture (UMA) Portability Lab Tutorial
- Chapter 7 Metadata Orchestration Tutorial
- Chapter 8 Service Graph Evolution Tutorial
- Chapter 9 Trust Boundaries Tutorial
- Chapter 10 Architectural Tradeoffs Tutorial
- Chapter 11 Evolution Without Fragmentation Tutorial
- Chapter 12 Discoverable Decisions Tutorial
- Chapter 13 Portable MCP Runtime Tutorial
Chapter 4 UMA code example
Feature flag evaluator tutorial
This tutorial walks through the first hands-on UMA example: a deterministic feature flag evaluator with one contract, one portable Rust core, a WASI executable, and a TypeScript parity implementation.
Keep the navigation close to the tutorial itself. Use the links below to move between the source folder, the examples index, and the next chapter without hunting through the footer.
What you will learn
- what belongs in the evaluator contract instead of the host adapter
- how first-match rule evaluation and sticky rollout decisions stay deterministic
- how Rust and TypeScript parity is proven from observable output
Prerequisites
- Rust with the wasm32-wasip1 target
- Wasmtime on your PATH
- Node.js 20 or newer for parity checks
- npm for TypeScript parity and optional adapters
Run this setup command before the lab if your machine does not already have the target installed.
rustup target add wasm32-wasip1
Full tutorial
- Enter the example
cd chapter-04-feature-flag-evaluator - List the guided labs
./scripts/list_labs.sh - Run the country match lab
./scripts/run_lab.sh lab1-country-match - Run the sticky rollout lab
./scripts/run_lab.sh lab2-rollout-match - Run the default fallback lab
./scripts/run_lab.sh lab3-default-fallback - Run the rule language lab
./scripts/run_lab.sh lab4-rule-language - Compare Rust and TypeScript behavior
./scripts/compare_impls.sh - Run the chapter smoke path
./scripts/smoke_flag_labs.sh
What to inspect
After each command, look for these proof points. They are the signals that connect the code example back to the UMA architecture claim.
- enabled
- matchedRule
- the same lab returning the same decision in Rust and TypeScript
Acceptance check
The chapter-level validation path is:
./scripts/smoke_flag_labs.sh
Return to the repository root for the final acceptance gate:
cd ..
./scripts/smoke_reader_paths.sh
Where to go next
Chapter 5 introduces the runtime layer around a pure service.