Skip to main content Skills Marketplace Discover and explore AI skills built by the community.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Show prompt details A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/bobmatnyc/claude-mpm-skills --skill axumThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Download Zip Downloading... More from this repository
Related occupations SOC
Based on SOC occupation classification
name axum description Axum (Rust) web framework patterns for production APIs: routers/extractors, state, middleware, error handling, tracing, graceful shutdown, and testing user-invocable false disable-model-invocation true version 1.1.1 category toolchain author Claude MPM Team license MIT progressive_disclosure {"entry_point":{"summary":"Build production Rust APIs with Axum using typed extractors, Tower middleware, structured errors, tracing, and testable routers","when_to_use":"When building Rust HTTP APIs/services that need predictable middleware composition, strong typing, and production-ready shutdown/observability patterns","quick_start":"1. Add axum + tokio + tower-http 2. Build Router with typed handlers 3. Define AppState + error type 4. Add tracing + timeouts 5. Test router with ServiceExt"},"token_estimate":{"entry":140,"full":5500}} context_limit 800 tags ["rust","axum","tokio","http","api","tower","middleware","tracing"] requires_tools []
Axum (Rust) - Production Web APIs
Overview
Axum is a Rust web framework built on Hyper and Tower. Use it for type-safe request handling with composable middleware, structured errors, and excellent testability.
Quick Start
Minimal server
✅ Correct: typed handler + JSON response
use axum::{routing::get, Json, Router};
use serde::Serialize;
use std::net::SocketAddr;
#[derive(Serialize)]
struct Health {
status: &'static str ,
}
async fn health () -> Json<Health> {
Json (Health { status: "ok" })
}
#[tokio::main]
async fn main () {
let app = Router::new ().route ("/health" , get (health));
let addr : SocketAddr = "0.0.0.0:3000" .parse ().unwrap ();
let listener = tokio::net::TcpListener::bind (addr).await .unwrap ();
axum::serve (listener, app).await .unwrap ();
}
❌ Wrong: block the async runtime
async fn handler () {
std::thread::sleep
from_secs
1
Core Concepts
Router + handlers Handlers are async functions that return something implementing IntoResponse.
use axum::{routing::get, Router};
fn router () -> Router {
let api = Router::new ()
.route ("/users" , get (list_users))
.route ("/users/:id" , get (get_user));
Router::new ().nest ("/api/v1" , api)
}
async fn list_users () -> &'static str { "[]" }
async fn get_user () -> &'static str { "{}" }
Extractors Prefer extractors for parsing and validation at the boundary:
Path<T>: typed path paramsQuery<T>: query stringsJson<T>: JSON bodiesState<T>: shared application state ✅ Correct: typed path + JSON
use axum::{extract::Path, Json};
use serde::{Deserialize, Serialize};
#[derive(Deserialize)]
struct CreateUser {
email: String ,
}
#[derive(Serialize)]
struct User {
id: String ,
email: String ,
}
async fn create_user (Json (body): Json<CreateUser>) -> Json<User> {
Json (User { id: "1" .into (), email: body.email })
}
async fn get_user (Path (id): Path<String >) -> Json<User> {
Json (User { id, email: "a@example.com" .into () })
}
Dependencies & Crate Structure If your crate is published as a library in addition to being built as a binary, isolate the HTTP stack to avoid bloating library consumers.
✅ Correct: optional HTTP feature
[dependencies]
axum = { version = "0.7" , optional = true }
tower-http = { version = "0.5" , optional = true }
tokio = { version = "1" , features = ["full" ] }
[features]
default = ["http-server" ]
http-server = ["axum" , "tower-http" ]
[[bin]]
name = "my-service"
required-features = ["http-server" ]
Library consumers (cargo add my-lib) get just the core logic without the HTTP overhead.
Binary builds include the server by default: cargo install my-crate works as expected.
Opt-out is explicit: cargo add my-crate --no-default-features for library use.
❌ Wrong: unconditional HTTP dependencies
axum = "0.7"
tower-http = "0.5"
Production Patterns
1) Shared state (DB pool, config, clients) Use State<Arc<AppState>> and keep state immutable where possible.
✅ Correct: AppState via Arc
use axum::{extract::State, routing::get, Router};
use std::sync::Arc;
#[derive(Clone)]
struct AppState {
build_sha: &'static str ,
}
async fn version (State (state): State<Arc<AppState>>) -> String {
state.build_sha.to_string ()
}
fn app (state: Arc<AppState>) -> Router {
Router::new ().route ("/version" , get (version)).with_state (state)
}
2) Structured error handling (IntoResponse) Centralize error mapping to HTTP status codes and JSON.
✅ Correct: AppError converts into response
use axum::{http::StatusCode, response::IntoResponse, Json};
use serde::Serialize;
#[derive(Debug)]
enum AppError {
NotFound,
BadRequest (&'static str ),
Internal,
}
#[derive(Serialize)]
struct ErrorBody {
error: &'static str ,
}
impl IntoResponse for AppError {
fn into_response (self ) -> axum::response::Response {
let (status, msg) = match self {
AppError::NotFound => (StatusCode::NOT_FOUND, "not_found" ),
AppError::BadRequest (_) => (StatusCode::BAD_REQUEST, "bad_request" ),
AppError::Internal => (StatusCode::INTERNAL_SERVER_ERROR, "internal" ),
};
(status, Json (ErrorBody { error: msg })).into_response ()
}
}
3) Middleware (Tower layers) Use tower-http for production-grade layers: tracing, timeouts, request IDs, CORS.
✅ Correct: trace + timeout + CORS
use axum::{routing::get, Router};
use std::time::Duration;
use tower::ServiceBuilder;
use tower_http::{
cors::{Any, CorsLayer},
timeout::TimeoutLayer,
trace::TraceLayer,
};
fn app () -> Router {
let layers = ServiceBuilder::new ()
.layer (TraceLayer::new_for_http ())
.layer (TimeoutLayer::new (Duration::from_secs (10 )))
.layer (CorsLayer::new ().allow_origin (Any));
Router::new ()
.route ("/health" , get (|| async { "ok" }))
.layer (layers)
}
4) Graceful shutdown Terminate on SIGINT/SIGTERM and let in-flight requests drain.
✅ Correct: with_graceful_shutdown
async fn shutdown_signal () {
let ctrl_c = async {
tokio::signal::ctrl_c ().await .ok ();
};
#[cfg(unix)]
let terminate = async {
tokio::signal::unix::signal (tokio::signal::unix::SignalKind::terminate ())
.ok ()
.and_then (|mut s| s.recv ().await );
};
#[cfg(not(unix))]
let terminate = std::future::pending::<()>();
tokio::select! {
_ = ctrl_c => {}
_ = terminate => {}
}
}
#[tokio::main]
async fn main () {
let app = app ();
let listener = tokio::net::TcpListener::bind ("0.0.0.0:3000" ).await .unwrap ();
axum::serve (listener, app)
.with_graceful_shutdown (shutdown_signal ())
.await
.unwrap ();
}
Ops: Graceful Shutdown in Supervised Environments Signal handling above is application-level. In production, your supervisor (systemd, launchd, container orchestrator) controls the actual termination window.
systemd (Linux) : Set KillSignal=SIGTERM and TimeoutStopSec=120 (or higher) in your .service file.
The default 90s timeout can fire mid-fsync on networked storage (EBS/EFS), truncating writes.
120s gives in-flight HTTP requests time to drain plus a safety margin for filesystem syncs.
launchd (macOS) : Use launchctl bootout (sends SIGTERM and waits) instead of launchctl kickstart -k (SIGKILL, truncates in-flight I/O).
Client-side reconnection : Have HTTP clients and MCP bridges connecting to the service implement exponential backoff (starting 200ms, capped at 30s) so brief restarts are transparent and don't cascade errors upstream.
Testing Test routers without sockets using tower::ServiceExt.
✅ Correct: request/response test
use axum::{body::Body, http::Request, Router};
use tower::ServiceExt;
#[tokio::test]
async fn health_returns_ok () {
let app : Router = super::app ();
let res = app
.oneshot (Request::builder ().uri ("/health" ).body (Body::empty ()).unwrap ())
.await
.unwrap ();
assert_eq! (res.status (), 200 );
}
Decision Trees
Axum vs other Rust frameworks
Prefer Axum for Tower middleware composition and typed extractors.
Prefer Actix Web for a mature ecosystem and actor-style runtime model.
Prefer Warp for functional filters and minimalism.
Anti-Patterns
Block the async runtime (std::thread::sleep, blocking I/O inside handlers).
Use unwrap() in request paths; return structured errors instead.
Run without timeouts; add request timeouts and upstream deadlines.
Resources 