Domain Web
Apply Rust web domain rules—async handlers, Arc state, extractors, and tower tracing—when designing HTTP, REST, GraphQL, or WebSocket services.
Overview
domain-web is an agent skill for the Build phase that encodes Rust web service constraints—async handlers, safe shared state, and request-scoped ownership—for HTTP and API work.
Install
npx skills add https://github.com/zhanghandong/rust-skills --skill domain-webWhat is this skill?
- Maps domain rules to Rust design: stateless HTTP → extractors, concurrency → async Send + Sync
- Critical rule: web handlers must not block; CPU work via spawn_blocking
- Shared state guidance: Arc<T> and Arc<RwLock<T>> for thread-safe handler state
- Request lifecycle: resources scoped to request duration via extractors and ownership
- Observability pattern: tracing integrated with tower layers
Adoption & trust: 615 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are building a Rust web API but risk blocking the async runtime, unsafe shared mutable state, or untraced requests under load.
Who is it for?
Indie builders implementing Rust REST, GraphQL, or WebSocket backends with axum/actix-family stacks and Cargo.toml web dependencies.
Skip if: Non-Rust web stacks, pure frontend work, or teams wanting copy-paste endpoint templates without architectural constraints.
When should I use this skill?
Building web services, HTTP servers, REST or GraphQL APIs, WebSocket endpoints, or when Cargo.toml indicates Rust web crates (axum, actix, tower, hyper).
What do I get? / Deliverables
Your agent applies documented domain-to-Rust implications so service design stays non-blocking, thread-safe, and observable.
- Architecture-aligned handler and middleware decisions traced to domain constraints
Recommended Skills
Journey fit
How it compares
Domain constraint reference for Rust APIs, not a project scaffold generator or OpenAPI-only spec skill.
Common Questions / FAQ
Who is domain-web for?
Rust developers and agent-assisted builders creating web servers and APIs who need consistent architectural rules across frameworks.
When should I use domain-web?
During Build/backend when designing routers, middleware, auth extractors, CORS, rate limits, or shared application state in Rust web crates.
Is domain-web safe to install?
It is documentation-style procedural knowledge with no required tools in frontmatter; review the Security Audits panel on this page like any third-party skill.
SKILL.md
READMESKILL.md - Domain Web
# Web Domain > **Layer 3: Domain Constraints** ## Domain Constraints → Design Implications | Domain Rule | Design Constraint | Rust Implication | |-------------|-------------------|------------------| | Stateless HTTP | No request-local globals | State in extractors | | Concurrency | Handle many connections | Async, Send + Sync | | Latency SLA | Fast response | Efficient ownership | | Security | Input validation | Type-safe extractors | | Observability | Request tracing | tracing + tower layers | --- ## Critical Constraints ### Async by Default ``` RULE: Web handlers must not block WHY: Block one task = block many requests RUST: async/await, spawn_blocking for CPU work ``` ### State Management ``` RULE: Shared state must be thread-safe WHY: Handlers run on any thread RUST: Arc<T>, Arc<RwLock<T>> for mutable ``` ### Request Lifecycle ``` RULE: Resources live only for request duration WHY: Memory management, no leaks RUST: Extractors, proper ownership ``` --- ## Trace Down ↓ From constraints to design (Layer 2): ``` "Need shared application state" ↓ m07-concurrency: Use Arc for thread-safe sharing ↓ m02-resource: Arc<RwLock<T>> for mutable state "Need request validation" ↓ m05-type-driven: Validated extractors ↓ m06-error-handling: IntoResponse for errors "Need middleware stack" ↓ m12-lifecycle: Tower layers ↓ m04-zero-cost: Trait-based composition ``` --- ## Framework Comparison | Framework | Style | Best For | |-----------|-------|----------| | axum | Functional, tower | Modern APIs | | actix-web | Actor-based | High performance | | warp | Filter composition | Composable APIs | | rocket | Macro-driven | Rapid development | ## Key Crates | Purpose | Crate | |---------|-------| | HTTP server | axum, actix-web | | HTTP client | reqwest | | JSON | serde_json | | Auth/JWT | jsonwebtoken | | Session | tower-sessions | | Database | sqlx, diesel | | Middleware | tower | ## Design Patterns | Pattern | Purpose | Implementation | |---------|---------|----------------| | Extractors | Request parsing | `State(db)`, `Json(payload)` | | Error response | Unified errors | `impl IntoResponse` | | Middleware | Cross-cutting | Tower layers | | Shared state | App config | `Arc<AppState>` | ## Code Pattern: Axum Handler ```rust async fn handler( State(db): State<Arc<DbPool>>, Json(payload): Json<CreateUser>, ) -> Result<Json<User>, AppError> { let user = db.create_user(&payload).await?; Ok(Json(user)) } // Error handling impl IntoResponse for AppError { fn into_response(self) -> Response { let (status, message) = match self { Self::NotFound => (StatusCode::NOT_FOUND, "Not found"), Self::Internal(_) => (StatusCode::INTERNAL_SERVER_ERROR, "Internal error"), }; (status, Json(json!({"error": message}))).into_response() } } ``` --- ## Common Mistakes | Mistake | Domain Violation | Fix | |---------|-----------------|-----| | Blocking in handler | Latency spike | spawn_blocking | | Rc in state | Not Send + Sync | Use Arc | | No validation | Security risk | Type-safe extractors | | No error response | Bad UX | IntoResponse impl | --- ## Trace to Layer 1 | Constraint | Layer 2 Pattern | Layer 1 Implementation | |------------|-----------------|------------------------| | Async handlers | Async/await | tokio runtime | | Thread-safe state | Shared state | Arc<T>, Arc<RwLock<T>> | | Request lifecycle | Extractors | Ownership via From<Request> | | Middleware | Tower layers | Trait-based composition | --- ## Related Skills | When | See | |------|--