
Domain Web
- 665 installs
- 1.3k repo stars
- Updated May 24, 2026
- zhanghandong/rust-skills
This is a copy of domain-web by actionbook - installs and ranking accrue to the original listing.
domain-web is a Rust layer-3 domain skill that enforces web service design rules for async handlers, Arc state, extractors, and tower tracing for developers building HTTP, REST, GraphQL, or WebSocket APIs in Rust.
About
domain-web is a Layer 3 domain-constraints skill in the zhanghandong/rust-skills stack for Rust web services, triggered on `**/Cargo.toml` paths. It maps domain rules—stateless HTTP, concurrency, middleware ordering, authentication—to Rust-specific design choices using axum, actix, warp, rocket, tower, hyper, and reqwest patterns. Developers reach for domain-web when designing handlers, extractors, Arc-backed shared state, JWT/session auth, CORS, rate limiting, and tower tracing middleware. The skill keeps web APIs stateless, concurrent, and testable by pushing globals into extractors and structured middleware stacks.
- 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
Domain Web by the numbers
- 665 all-time installs (skills.sh)
- +8 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Security screen: LOW risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/zhanghandong/rust-skills --skill domain-webAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 665 |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | zhanghandong/rust-skills ↗ |
How do you structure async Rust web API handlers?
Apply Rust web domain rules—async handlers, Arc state, extractors, and tower tracing—when designing HTTP, REST, GraphQL, or WebSocket services.
Who is it for?
Rust developers building axum, actix, or tower-based HTTP, REST, GraphQL, or WebSocket services who need domain-level architectural constraints.
Skip if: Developers writing CLI tools, embedded firmware, or frontend-only code with no Rust web server in the project.
When should I use this skill?
The user builds Rust web servers, APIs, middleware, auth, or WebSocket services and `Cargo.toml` is present in the workspace.
What you get
Stateless Rust handlers, Arc-managed shared state, extractor-based dependencies, and tower-traced middleware stacks.
- Handler and extractor design
- Middleware and tracing setup
- Auth and routing patterns
Files
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 workState Management
RULE: Shared state must be thread-safe
WHY: Handlers run on any thread
RUST: Arc<T>, Arc<RwLock<T>> for mutableRequest 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
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 |
|---|---|
| Async patterns | m07-concurrency |
| State management | m02-resource |
| Error handling | m06-error-handling |
| Middleware design | m12-lifecycle |
Related skills
How it compares
Choose domain-web over generic Rust style guides when you need web-specific domain constraints tied to axum/tower handler and middleware architecture.
FAQ
How does domain-web handle shared state in Rust web apps?
domain-web enforces stateless HTTP by avoiding request-local globals and placing shared data in Arc-backed state passed through extractors, matching axum and tower handler design for concurrent Rust APIs.
Which Rust web frameworks does domain-web cover?
domain-web addresses axum, actix, warp, rocket, tower, hyper, and reqwest patterns for HTTP, REST, GraphQL, WebSocket, middleware, authentication, CORS, and rate limiting in `Cargo.toml` projects.
Is Domain Web safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.