Axum
By the Tokio project
Axum is a web application framework for the Rust programming language, built directly on top of the Tokio async runtime and the Tower ecosystem of middleware and service abstractions. It lets developers build HTTP servers and APIs using an…
Definition
Axum is a web application framework for the Rust programming language, built directly on top of the Tokio async runtime and the Tower ecosystem of middleware and service abstractions. It lets developers build HTTP servers and APIs using an extractor-based routing model, where handler functions declare the pieces of a request they need — path parameters, JSON bodies, headers, or shared state — as typed function arguments rather than parsing a raw request object manually.
Overview
Axum addresses a specific gap in the Rust web ecosystem: teams wanted the ergonomics of frameworks like Flask or Express, where routes read as plain functions, without sacrificing Rust's compile-time guarantees or giving up direct access to the broader async ecosystem. Earlier Rust frameworks either hid Tokio behind their own runtime or required verbose boilerplate to compose middleware. Axum was written by contributors to the Tokio project specifically to interoperate cleanly with existing Tower-based services. Mechanically, Axum routes work through a trait called `FromRequest`, which extractors implement to pull typed values out of an incoming HTTP request. A handler function lists these extractors as parameters — for example a `Json<CreateUser>` argument automatically deserializes and validates the request body, while a `State<AppState>` argument pulls shared application state out of the router. If extraction fails, Axum converts the error into an HTTP response automatically, so handlers can focus on business logic rather than manual error plumbing. Routing itself is a tree matched against the request path and method, and middleware is added as `Tower` layers that wrap handlers or entire routers, giving access to the same ecosystem of rate limiters, tracing layers, and compression services used across other Tower-based Rust projects. Within the Rust web space, Axum sits alongside Actix Web and Rocket as one of the three most commonly chosen frameworks. Actix Web has historically emphasized raw throughput benchmarks and predates Axum by several years, while Rocket prioritizes a more declarative, macro-heavy API with strong compile-time route checking. Axum differentiates itself by minimizing its own abstractions in favor of exposing Tokio and Tower primitives directly, which means code written for Axum often composes more easily with other async Rust libraries that also target Tower. In practice, teams reach for Axum when building REST or JSON APIs, WebSocket servers, or backend services that need to share infrastructure code — like authentication middleware or observability layers — across multiple services via Tower. It is commonly paired with an async database library such as SQLx or an ORM like Diesel's async variants, and with `serde` for JSON serialization. Because it has no bundled ORM, templating engine, or CLI scaffolding tool, adopting Axum usually means assembling a stack from separate crates rather than following one opinionated project structure. The trade-off is that Axum's flexibility shifts more integration decisions onto the developer compared to more batteries-included frameworks. Newcomers to Rust's async model can find the trait bounds involved in custom extractors or middleware confusing, since compiler errors around `Send`, `Sync`, and lifetime requirements are common early friction points. Teams that want a fully bundled framework with built-in database tooling, or that are not otherwise committed to Tokio as their async runtime, are usually better served by a different choice, since Axum's design assumes Tokio underneath it rather than remaining runtime-agnostic.
Key Features
- Extractor-based handlers that pull typed data out of requests as function arguments
- Built directly on the Tokio async runtime with no separate runtime abstraction
- Full interoperability with Tower middleware, services, and layers
- Macro-free routing API that relies on ordinary Rust functions and types
- Automatic conversion of extraction and handler errors into HTTP responses
- First-class support for WebSocket upgrades and streaming responses
- Shared application state passed through the router via typed state extractors
- Compile-time checking of route handler signatures against declared extractors