axum-core-architecture

What problem does it solve?

It prevents confusion about how Axum actually works by explaining its tokio + hyper + tower composition, the full request lifecycle, and the correct architectural boundaries—so you stop guessing when handlers fail to compile or servers exit immediately.

Core Features & Use Cases

• Clarifies Axum’s layered architecture: maps every concern to the owning layer (tokio for runtime, hyper for HTTP, tower for services/middleware, Axum for routing/extraction/dispatch).
• Explains the server entry point correctly: covers why axum::serve is the glue, what it requires, and why it never returns normally.
• Diagnoses the most common “Handler is not satisfied” failure mode: explains how #[debug_handler] turns cryptic trait-bound failures into actionable causes.
• Guides dependency choices: distinguishes when to depend on axum versus axum-core (especially for library authors implementing FromRequest/FromRequestParts/IntoResponse).

Quick Start

Ask Claude to explain how your proposed Axum handler and server entry point fit into the tokio-hyper-tower-Axum request lifecycle and identify which layer owns each responsibility.