
Domain Web
- 1.4k installs
- 1.3k repo stars
- Updated May 24, 2026
- actionbook/rust-skills
domain-web is a Rust skill for web service domain constraints, async handlers, state management, and axum API patterns.
About
The domain-web skill is Layer 3 domain constraints for Rust web services covering HTTP, REST, GraphQL, WebSocket, and middleware design. Critical rules require non-blocking async handlers, thread-safe shared state via Arc and Arc<RwLock<T>>, and request-scoped resource lifetimes through extractors. Framework comparison maps axum for modern tower-based APIs, actix-web for performance, warp for composable filters, and rocket for rapid macro-driven development. Key crates include axum, reqwest, serde_json, jsonwebtoken, tower-sessions, sqlx, and tower middleware layers. Design patterns document extractors like State and Json, unified AppError IntoResponse mapping, tower middleware stacks, and Arc AppState for configuration. Axum handler example shows State db pool with Json payload and structured error responses. Common mistakes warn against blocking handlers, Rc in shared state, missing validation, and absent error responses. Trace-down tables link concurrency, type-driven validation, and lifecycle patterns to related rust-skills modules for deeper implementation guidance.
- Web handlers must be async; blocking work belongs in spawn_blocking.
- Shared application state requires Arc or Arc<RwLock<T>> for Send plus Sync safety.
- Framework table compares axum, actix-web, warp, and rocket strengths.
- Axum pattern uses State extractors, Json payloads, and IntoResponse error types.
- Common mistakes cover blocking handlers, Rc in state, and missing validation.
Domain Web by the numbers
- 1,351 all-time installs (skills.sh)
- +50 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Ranked #335 of 4,386 Backend & APIs skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
domain-web capabilities & compatibility
- Capabilities
- async non blocking handler rules · arc shared state patterns · framework comparison guidance · extractor and error response design · tower middleware composition
- Use cases
- api development
What domain-web says it does
Web handlers must not block
Shared state must be thread-safe
npx skills add https://github.com/actionbook/rust-skills --skill domain-webAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.4k |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | actionbook/rust-skills ↗ |
How do I structure Rust web handlers with safe shared state and non-blocking async patterns?
Apply Rust web service domain constraints for async handlers, state management, middleware, and framework selection with axum patterns.
Who is it for?
Rust developers building axum or actix HTTP APIs with domain-driven constraint guidance.
Skip if: Skip when the task is CLI tooling without HTTP servers; use other actionbook domain skills.
When should I use this skill?
User builds Rust web servers, REST APIs, middleware, or asks about axum state extractors.
What you get
Framework-aware Rust web designs with extractors, tower middleware, and validated error responses.
- Architecture constraint mappings
- Handler and middleware design decisions
By the numbers
- Covers 7 Rust web frameworks/tools: axum, actix, warp, rocket, tower, hyper, reqwest
- Layer 3 domain skill scoped to `**/Cargo.toml` glob pattern
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
Forks & variants (1)
Domain Web has 1 known copy in the catalog totaling 665 installs. They canonicalize to this original listing.
- zhanghandong - 665 installs
How it compares
Pick domain-web over generic REST guides when Rust-specific extractor, middleware, and concurrency constraints must drive axum or actix architecture decisions.
FAQ
Which framework does the skill favor?
axum with tower for modern APIs; table also covers actix-web, warp, and rocket.
How should shared state be stored?
Arc<T> or Arc<RwLock<T>> because handlers must be Send and Sync across threads.
What if a handler blocks?
Use async await and spawn_blocking for CPU work to avoid latency spikes.
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.