Chapter-aligned
The examples map directly to the later chapters so the learning path continues from explanation into runnable material.
UMA examples
The examples are the practical proof layer of Universal Microservices Architecture. They let readers inspect how a portable service is defined, how a runtime wraps it, how orchestration emerges from metadata, and how system evolution and trust decisions become visible rather than hidden inside operational glue. They are the fastest way to evaluate UMA as an execution model instead of treating it as another architectural slogan.
Why the examples matter
Architecture claims are easy to make and hard to validate. The examples exist to close that gap. They give the reader a way to compare intention against output, contracts against runtime decisions, and design coherence against the real drift that appears once a system grows.
The key thing to evaluate is not “can this code run somewhere else?” It is whether one behavior stays coherent while compute can happen in many places and the runtime decides where logic runs.
A before-and-after way to read the repo
Before UMA, a team often ends up with the same business rule scattered across browser logic, edge handling, backend checks, and workflow glue. After UMA, the question becomes whether one portable behavioral unit can stay intact while the runtime takes responsibility for placement, validation, trust, and workflow approval.
That is the lens to use when reading the examples. Do not ask only whether the lab runs. Ask whether the architecture still knows what the durable behavior is and why the runtime approved the path that produced the result.
What makes these examples different
These examples are not generic demos attached to a book launch. Each one exists to make a specific architectural question visible. What does a portable service boundary look like? What belongs in the runtime layer? How does metadata shape orchestration? When do trust and compatibility become part of the architecture rather than operational cleanup?
That makes the examples valuable even outside the book flow. A reader can inspect one example in isolation and still learn something important about portability, runtime governance, or long-term system design. Used in sequence, they become a practical walk through the model.
Rust-first
The primary validated path uses Rust for the core runtime and architecture examples.
TypeScript parity
Selected chapters include TypeScript parity paths to make comparison easier for readers coming from different stacks.
Reader-tested flows
Scripts, smoke checks, and learning-path validation make the examples easier to follow chapter by chapter.
What you can do with them
Use the examples to test the book’s architectural claims against concrete behavior. You can run a minimal service, trace a runtime wrapper, compare implementations, follow orchestration decisions, and see where trust and compatibility start to matter.
They also give teams a way to discuss architecture with evidence. Instead of debating portability or coherence in abstract terms, readers can point to actual contracts, runtime outputs, and learning-path transitions.
That proof should include measurable tradeoffs, not just screenshots. The benchmark notes now publish local artifact sizes and repeated execution timings for the early portability chapters so readers can evaluate UMA with numbers as well as examples.
How the repository is organized
The repository follows the same broad progression as the learning path. Earlier chapters keep the system intentionally small. Later chapters introduce orchestration, service graphs, trust boundaries, and governed evolution. That organization helps the reader understand not just individual samples, but the architectural consequences of adding more runtime responsibility over time.
The latest steps in that progression are the Chapter 12 lab on discoverable decisions and the Chapter 13 portable MCP runtime, where projections, proposals, validation feedback, approved execution, MCP discovery, and event-driven composition become first-class outputs instead of hidden runtime behavior.
By then, the examples are proving something stronger than execution. They are proving that a governed system can expose its own reasoning surfaces as reusable architectural artifacts.
Why Rust-first matters here
The validated default path uses Rust because it makes the portable runtime story concrete and rigorous. TypeScript parity is included where it adds value for comparison, but the repository stays centered on one primary validated path so the learning experience remains consistent and defensible.
What the closing examples prove
The Chapter 12 example matters because it demonstrates a final architectural shift: a system should not only execute correctly, it should expose why it acted. That lab makes decision stages queryable so readers can inspect capability projection, proposal shape, authority feedback, bounded revision, approved execution, and full traceability in one sequence.
Chapter 13 then carries that idea into a richer reference experience. The runtime discovers distributed capabilities through MCP-style descriptors, evaluates compatibility and constraints, accepts or rejects agent proposals, coordinates event-driven execution, and produces a structured French report without collapsing back into a hardwired workflow.
If you want one conceptual lens that makes the Chapter 13 behavior easier to read, focus on the distinction between planning and authority. The agent can help propose a workflow, but the runtime still governs what is approved and executed.
That is also the cleanest demonstration of the UMA promise: not write once, run everywhere, but write once, run where it makes sense under visible runtime authority.
Frequently asked question
Do I need to run every example to understand UMA?
No, but the examples are where the architectural claims become easiest to verify. Even running a few of the core chapters gives much more confidence in the model than reading about it alone.
The examples live in the public repository and follow the same story arc as the site and the book. That makes the repository the right place to continue after this overview. If you want the full design reasoning behind that progression, the book takes the same examples and connects them into one architectural sequence rather than a set of isolated labs.