Build a Rust One Web application#

The executable example is systems/system-idl/examples/order-review-web. It is a standalone product rather than another root inside a TypeScript application.

1. Select the Rust application#

Its one.one selects three authored sources and one exact lock:

semantic order.review
    domain one.project@1
    project OrderReviewWeb@1
        source ./one/contracts.one
        source ./one/application.one
        source ./one/system.one
        lock ./one.lock

The application and root use the ordinary manifestless Rust web path:

semantic order.review.build
    domain one.build@1
    application Web@1
        profile one.rust#ServerHtmlApplication@1
        workspace ../../../..
        source ./src/lib.rs
        source ./src/main.rs
        source ./src/style.css
        entry process ./src/main.rs
        dependency runtime cargo(name: "one", exact: 0.1.0, source: workspace)

semantic order.review.system
    domain one.system@1
    component Web@1
        owner order.review#Product@1
        provide service order.review#Review@1
        require one.deployment.local.release#Apply@1
        require one.history.durable#Append@1

    system OrderReview@1
        root order_review_web
            include Web
            source Web from order.review.build#Web@1
            build development
            build release
            build reproducible

2. Write only the product#

src/lib.rs implements one::web::server::Application. It owns:

• the initial review snapshot;
• positive customer and order identifier checks;
• the 4,096-byte order-details rule;
• success and rejection copy; and
• the view! page presentation over the public fluent document builder.

The reusable facade owns all generic server work. The product has no handwritten listener, request parser, route matcher, response framing, percent decoder, or HTML encoder. It also has no Cargo.toml, Cargo.lock, or package.json: Build projects the exact Cargo package and lock as disposable inputs beneath .one/build/work from the authored source and dependency selection above.

The operation implementation is Rust too. Its checked .one implementation item selects one.language.rust#OwnedAsync@1, re-exports the Rust request and service symbols, and one::service::pure adapts the product rule without a handwritten async service wrapper. .one declares the canonical meaning and selection; it does not execute the request or introduce a TypeScript runtime.

src/main.rs only selects an address and calls serve(OrderReview, address). The stylesheet is a static Build input and the resulting page works with scripts disabled.

3. Verify the Rust boundary#

cargo test -p one --features server-html --lib web::tests --locked
cargo test -p one-adapter-renderer-server-html --locked
one test --workspace systems/system-idl/examples/order-review-web \
  --root order_review_web --offline

The facade and renderer crates own their direct Rust checks. The product test uses the same manifestless source selection and canonical root as every later lifecycle step.

4. Run it#

Build and apply the release through the lifecycle below, then open its reported local address. Set ORDER_REVIEW_WEB_ADDRESS in the owned execution configuration to choose another machine-local binding.

5. Use the canonical lifecycle#

one check --workspace systems/system-idl/examples/order-review-web --offline
one test --workspace systems/system-idl/examples/order-review-web \
  --root order_review_web --offline
one invoke order.review#Review.Check@1 request.json \
  --workspace systems/system-idl/examples/order-review-web \
  --root order_review_web --offline
one plan --workspace systems/system-idl/examples/order-review-web \
  --root order_review_web --offline
one build --workspace systems/system-idl/examples/order-review-web \
  --root order_review_web --offline

Use {"customer_id":"7","order_id":"42"} as request.json. Continue with the exact Build through one release local, then use its plan:revision:sha256:... reference for one apply, a second idempotent one apply, and one inspect. Those commands use the same selected source and lock as the product; Cargo checks execute inside Build's disposable projection, not through a second product manifest.

See One Web for the API boundary and authority and trust for effect authorization.