Why share request and response structs between a Rust service and CLI when practical?

It keeps the client and server contract aligned.

It makes all errors impossible.

A teammate wants to hide clap inside a convenient helper. What should you check first?

Whether the helper makes ownership, inputs, failures, and tests easier to review.

Whether it reduces the number of files regardless of behavior.

Whether it removes the need for the lesson checklist.

Whether it can skip the production signals for this course.

Which artifact best proves this Rust Systems lesson is ready for review?

A repeatable check tied to tokio and cargo test output.

A note that says the happy path was manually clicked once.

A screenshot with no command, test, or failure-mode context.

A broad refactor that avoids the specific lesson outcome.

Intermediate async tooling: a teammate says the happy path works, but "CLI contract" is still implicit. What should you ask for before merging?

A small contract, test, or review artifact that proves cli contract under a realistic failure case.

Skip compiler, OpenAPI, SQL, or host evidence until the capstone.

Hide the decision inside framework defaults so reviewers have less to read.

Treat production behavior as separate from the lesson implementation.

A reviewer has five minutes to evaluate this intermediate Rust Systems slice. Which evidence is strongest?

A focused artifact for release check script plus a repeatable test, log, OpenAPI diff, or deployment check.

A passing build with no note about contracts, query shape, or operations.

A screenshot of Swagger without checking response or failure cases.

A broad rewrite that does not map to the stage milestone.

Learn / Rust Practical Systems

CLI, Async Persistence, and Release

Create a companion CLI, persist service state with sqlx-style repositories, and run release checks.

Course: Rust Practical Systems. Level: Intermediate. Topic: Systems reliability.

Stage: intermediate - Intermediate async tooling - CLI, async persistence, and release commands. Connect a Rust service to a companion CLI, async persistence boundary, and repeatable release checks.

Outcomes

Parse typed command-line arguments.
Use async repositories behind application state.
Run fmt, clippy, tests, and documented release commands.

Concepts

clap
tokio
sqlx pool
cargo clippy

Concept flow

Show how cli, async persistence, and release commands moves from trigger to implementation outcome in Rust Systems.

CLI command
HTTP client
Axum API
Repository
Database
Release checks

Session flow

Model clap (concept, 12 min) — Name the decisions behind clap before writing code.
- Parse typed command-line arguments.
- Explain where clap belongs in job orchestration service.
Build the vertical slice (walkthrough, 22 min) — Implement the smallest useful slice in src/bin/jobctl.rs.
- Use async repositories behind application state.
- Connect tokio to a working example.
Verify and harden (exercise, 14 min) — Run cargo fmt, clippy, and test before release.
- Run fmt, clippy, tests, and documented release commands.
- Record one risk or follow-up before moving on.

Code example

Rust in src/bin/jobctl.rs.

#[derive(clap::Parser, Debug)]
      struct Args {
          #[arg(long, env = "SERVICE_URL")]
          service_url: String,
      
          #[arg(long, default_value_t = 30)]
          timeout_seconds: u64,
      }

Walkthrough examples

CLI, Async Persistence, and Release in a job orchestration service — A team is extending an Axum service with a companion CLI and needs this lesson's pattern to be clear enough for review, testing, and future maintenance.
- File: src/bin/jobctl.rs
- File: tests/cli-async-persistence-and-release.spec
- File: docs/rust-systems/cli-async-persistence-and-release.md
- Start from the provided Rust snippet and make the intent visible in names and boundaries.
- Apply the checklist item "CLI has help output" before adding extra behavior.
- Write down how the implementation changes when tokio fails or becomes slow.

Practice

Add a submit command to a CLI.
Store jobs through a repository trait.
Run cargo fmt, clippy, and test before release.

Checklist

CLI has help output
Async database calls use shared state
Background tasks observe shutdown
Release commands are documented

Quiz prompts

Why share request and response structs between a Rust service and CLI when practical? — Shared models reduce drift between the service API and companion tooling.
A teammate wants to hide clap inside a convenient helper. What should you check first? — Place clap at the boundary that keeps job orchestration service behavior explicit, testable, and reviewable.
Which artifact best proves this Rust Systems lesson is ready for review? — Production-ready learning needs evidence: a test, trace, command, screenshot, or log that catches the risk again.
Intermediate async tooling: a teammate says the happy path works, but "CLI contract" is still implicit. What should you ask for before merging? — CLI contract belongs in the intermediate stage only when the decision is visible, testable, and tied to a realistic failure mode.
A reviewer has five minutes to evaluate this intermediate Rust Systems slice. Which evidence is strongest? — Ship an intermediate Rust tool/service slice with CLI help output, async persistence boundary, and release-check evidence.

Flashcards

Intermediate async tooling: what decision does "CLI contract" force you to make? Make flags, help text, exit codes, and output formats stable enough for automation. Evidence prompt: Add one CLI command and snapshot the help output.
Intermediate async tooling: what decision does "Async persistence boundary" force you to make? Keep database calls behind async functions that return typed domain results. Evidence prompt: Move one persistence call behind an async repository function and test the error path.
Intermediate async tooling: what decision does "Release check script" force you to make? Run format, lint, tests, and package checks as one repeatable release command. Evidence prompt: Create a release command log with expected passing output.
In Rust Systems, what should you remember about clap? clap matters here because it supports "Parse typed command-line arguments.".
In Rust Systems, what should you remember about tokio? tokio matters here because it supports "Use async repositories behind application state.".
In Rust Systems, what should you remember about sqlx pool? sqlx pool matters here because it supports "Run fmt, clippy, tests, and documented release commands.".
In Rust Systems, what should you remember about cargo clippy? cargo clippy matters here because it supports "Parse typed command-line arguments.".

Labs

Ship a cli, async persistence, and release slice — Extend an Axum service with a companion CLI with a small but reviewable feature that proves the lesson's architecture in code.
- Ship an intermediate Rust tool/service slice with CLI help output, async persistence boundary, and release-check evidence.
- Add one CLI command and snapshot the help output.
- Move one persistence call behind an async repository function and test the error path.
- Create a release command log with expected passing output.
- Add a submit command to a CLI.
- Store jobs through a repository trait.
- The lab demonstrates the intermediate async tooling outcome without skipping earlier contract evidence.
- Each subtopic has a concrete artifact: CLI contract, Async persistence boundary, Release check script.
- The review notes explain how this level changes ownership, verification, or operational risk.

Challenge

Review-ready cli, async persistence, and release (Stretch) — Ship an intermediate Rust tool/service slice with CLI help output, async persistence boundary, and release-check evidence.
- All checklist items are either implemented or documented with a reason.
- The change can be understood from src/bin/jobctl.rs plus one short note.
- The concept diagram names ownership, failure handling, and verification points.
- A teammate could run the verification steps without asking for hidden context.

Canonical lesson URL