Which Rust framework should you choose? When none is the obvious choice

A backend application has one main mission: receive requests, process them, and respond. These requests almost always arrive over HTTP, the protocol of the web: that is the case for a REST API, called by a browser or a mobile app.

Let’s take an example that will follow us through the whole article: my-api, a small fictional service written in Rust. It serves articles. A client asks it for article no. 42. Let’s follow its request, from arrival to response:

Steps 1 to 4 look alike from one application to the next, and nobody wants to rewrite them every time. That is the framework’s job:

Yet in the diagram, only one step has the framework’s color. The first three are provided by foundations: libraries shared by almost every Rust framework, which the standard library does not provide. Let’s compare with Java, where the framework does everything:

Where these layers live: crates

What you can hand over to the framework

Not every framework does as much. The most minimalist stop at routing and reading requests; the most integrated also decide on the database, background jobs, even the user interface. Every decision it makes is one you won’t have to make, and one you can no longer make any other way.

These two ideas, what the framework replaces in the foundations and what you hand over to it above them, will become the first two criteria in part 3.

The absence of one big framework in Rust is neither a delay nor an accident. It follows from choices made by the language, and from an eventful history. Together they explain why, in the journey from part 1, the foundations do most of the work.

A standard library that stops short of networking

Part 1 showed it: Rust’s standard library provides none of the steps in the journey. Compare it with Go’s, the other language where no framework has become the obvious choice:

This is a deliberate choice: whatever goes into Rust’s standard library stays there forever, with a compatibility promise that has no end date. But HTTP keeps moving (HTTP/2, then HTTP/3), and the right way to run asynchronous code depends on the machine, from server to microcontroller. So Rust left all of that to crates. And as soon as there is a dependency, there is a choice.

Async arrived late, and its engine stayed outside

The async and await keywords have only been stable in Rust since November 2019 (version 1.39). The language defines what an asynchronous task is, but not who runs it: you need a runtime, and for years two of them fought for the spot, tokio and async-std. A library written for one didn’t always work with the other, and every framework had to place a bet.

tokio won: version 1.0 in December 2020, then widespread adoption. In February 2025, async-std was officially discontinued. Tide, the web framework built on it, hasn’t published a release since December 2021: remember that name, it will come back as a lesson.

The foundations have only been stable for a short while: hyper, the HTTP library almost everyone uses, only released its 1.0 in November 2023. Spring Boot was built on a Java platform nearly twenty years old; Rust frameworks were built while the ground was still shifting. None had time to crush the others.

No reflection, so no runtime magic

Much of Spring’s power rests on reflection: a Java program’s ability to inspect itself while it runs. At startup, Spring scans your classes, reads their annotations and injects dependencies wherever you asked for them. You annotate, and it works.

Rust has no runtime reflection: a framework cannot “discover” your code at startup. Everything is resolved at compile time, through types, traits and macros. Compare:

@RestController
class ArticleController {
    // injected at startup, via reflection
    @Autowired ArticleRepository repo;

    @GetMapping("/articles/{id}")
    Article get(@PathVariable long id) {
        return repo.findById(id).orElseThrow();
    }
}

// an ordinary function: its parameters state
// what it expects, and the compiler checks it
async fn article(
    State(db): State<Db>,
    Path(id): Path<u64>,
) -> Result<Json<Article>, StatusCode> {
    db.find(id).await.map(Json).ok_or(StatusCode::NOT_FOUND)
}
// … and you are the one who passes the state to the router:
// Router::new().route(…).with_state(db)

On the Spring side, the framework does a huge, invisible amount of work. On the Rust side, there is no injection container: state is passed explicitly, and the function signature is the contract. If a parameter can’t be extracted from the request, the code doesn’t compile. Hence the most important idea of this part:

In Rust, the type system does part of the work a framework does elsewhere. The framework no longer needs to be a platform: it can settle for being a well-typed router.

A culture of composition

The Rust ecosystem got used very early to small crates that do one thing, very well: serde for serialization, tracing for logs and traces, sqlx for the database. None of them belongs to a framework, and that is by design. A weakness, because you have to assemble things yourself; a rare strength, because you can swap one brick without moving house. The rest of the article is about figuring out which of the two matters more to you.

What this history produced: shared foundations

The result: in almost every Rust backend in production, you find the same layers, those of steps 1 to 4 of the journey. The framework sits on top, and it isn’t the thickest one. The diagram below shows them for each framework, with the colors from part 1:

pub trait Service<Request> {
    type Response;
    type Error;
    type Future: Future<Output = Result<Self::Response, Self::Error>>;

    // “Are you ready to receive a request?”: backpressure is part of the contract.
    fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>>;

    // Handle the request: the response will come later.
    fn call(&mut self, req: Request) -> Self::Future;
}

The consequence is decisive: in the tower world, a middleware layer is simply a service that wraps another one (a Layer). Written once, a layer wraps any service, whatever the framework:

let app = Router::new()
    .route("/articles/{id}", get(article))
    .layer(CompressionLayer::new())      // tower-http: gzip, brotli…
    .layer(CorsLayer::permissive())      // tower-http: CORS headers
    .layer(TraceLayer::new_for_http());  // tower-http: one trace per request, via tracing
// The same layers can wrap a tonic gRPC server.

That is the secret behind the rise of axum, released only in 2021: it arrived in an ecosystem that already existed, and was just waiting for a router. axum is not a framework that created its ecosystem: it is an ecosystem that found its framework.

Two families, and a few independents

Depending on which layers each framework reuses or reinvents, the landscape falls into two families: the tower family, which shares its middleware with the whole ecosystem, and the independents, each with its own model, sometimes very well done, but apart.

This table doesn’t look like much. Yet it holds the most structuring criterion in this article, and the least discussed. We’ll come back to it in part 3.

What it changes for you

To compare tools this different, you need a grid. It has eight criteria. The first two follow directly from part 2 and draw the map of the candidates; the other six refine it. And the one people always cite first, speed, barely makes the list.

1. 1The distance from the shared foundations
2. 2The level of integration
3. 3Maintenance
4. 4API stability
5. 5The execution model
6. 6Compile errors
7. 7The API contract
8. 8The team
9. ✕Raw speed

1The distance from the shared foundations, the criterion that matters most

The Rust ecosystem has unified beneath the framework, in tokio, hyper and tower. So a Rust framework is judged first by how much of them it keeps:

This distance comes at two prices:

The day you leave comes more often than you’d think. That’s what happened with Tide:

How to measure it: the middleware model

The distance can be read in a single line, at step 3 of the journey: what you have to implement to write middleware. The shared tower contract, or a homegrown model? Here is each framework’s answer:

Here is what that changes for two identical projects, one written with axum, the other with Actix Web, when the time comes to leave:

That’s not a flaw: it’s a trade-off. But it’s decided on day one, not on the day you leave.

2The level of integration, the second axis

Rust delivers the backend as a kit. Some frameworks give you the parts and the instructions; others, the furniture already assembled. These are the eight decisions from part 1, laid out on a line:

Toward the right, you save time at the start, and you depend on someone else’s choices: Loco chose SeaORM for you, a gift if you had no opinion, a constraint if you preferred sqlx. Toward the left, you write more glue code, but that code is yours. And the two axes are independent: Loco sits far along this one, yet very close to the foundations on the first, since it’s built on axum.

The six other criteria

Once these two axes are set, the remaining question is what each framework is worth day to day. Six criteria tell you.

What about speed?

All these frameworks are very fast. On a server that returns a string, Actix Web often gets a slight edge from its per-core runtime; on a real service, which queries a database and serializes JSON, these gaps get lost in everything else. So raw speed joins the things that shouldn’t weigh in:

If performance really matters, there’s only one method: a prototype of the busiest endpoint, in two frameworks, with the real database and a realistic load. One day of work, worth more than a hundred benchmarks read online.

With these criteria in hand, we can reframe the starting question.

The first question has no answer: comparisons line up benchmarks and conclude with “it depends,” without ever saying on what. The second has one, different for each project. I’ll also say which one I like best, and why.

Each half of the right question is weighed with the criteria from part 3:

To apply it, seven concrete questions, to ask as a team before writing the first route. The answers almost always point to the right candidate:

1. What don’t the foundations give me?criteria 2 to 8Make a list, in writing. If it’s short, axum and a few crates may be enough.
2. How many decisions do we want to hand over to the framework?criterion 2Configuration, database, background jobs, emails: a team in a hurry gains by delegating them, a team with opinions gains by keeping them.
3. Will we need gRPC, serverless, middleware we won’t write ourselves?criterion 1If the answer is “maybe,” the tower family is insurance that costs almost nothing.
4. Who consumes this API?criterion 7Your own applications, or partners? If a published contract is a deliverable, it may choose the framework for you.
5. Who will maintain this code?criteria 5, 6 and 8Not today’s team: the one three years from now. What it knows about Rust, and what it will easily find online.
6. Who maintains the tool, and how often does it break?criteria 3 and 4Date of the last release, number of active maintainers, version number: 0.x or 1.0.
7. Does my business code import the framework?criterion 1The answer must be no, whatever tool you choose. It’s the only rule that applies to every candidate.

Six candidates, ordered from closest to the shared foundations to farthest. For each one: an overview, where it stands on the eight criteria, the situations where it fits best, its challenges and risks, and my verdict.

Each card includes the same endpoint, collapsed: GET /articles/{id}, which reads an article from a shared database and returns JSON, or a 404. The Db type is the same everywhere: only the framework changes.

async fn article(
    State(db): State<Arc<Db>>,
    Path(id): Path<u64>,
) -> Result<Json<Article>, StatusCode> {
    db.find(id).await.map(Json).ok_or(StatusCode::NOT_FOUND)
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/articles/{id}", get(article))
        .with_state(Arc::new(Db::connect().await));
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

# install the tool, then create the project (it asks a few questions: database, app type)
cargo install loco
loco new

# generate the model, the migration, the controller and its routes
cargo loco generate scaffold article title:string! content:text --api
cargo loco start

#[handler]
async fn article(Data(db): Data<&Arc<Db>>, Path(id): Path<u64>) -> poem::Result<Json<Article>> {
    db.find(id).await.map(Json).ok_or_else(|| Error::from_status(StatusCode::NOT_FOUND))
}

#[tokio::main]
async fn main() -> Result<(), std::io::Error> {
    let app = Route::new()
        .at("/articles/:id", get(article))
        .data(Arc::new(Db::connect().await));
    Server::new(TcpListener::bind("0.0.0.0:3000")).run(app).await
}

#[handler]
async fn article(req: &mut Request, depot: &mut Depot) -> Result<Json<Article>, StatusError> {
    let id: u64 = req.param("id").ok_or_else(StatusError::bad_request)?;
    let db = depot.obtain::<Arc<Db>>().map_err(|_| StatusError::internal_server_error())?;
    db.find(id).await.map(Json).ok_or_else(StatusError::not_found)
}

#[tokio::main]
async fn main() {
    let db = Arc::new(Db::connect().await);
    let router = Router::new()
        .hoop(affix_state::inject(db))
        .push(Router::with_path("articles/{id}").get(article));
    let acceptor = TcpListener::new("0.0.0.0:3000").bind().await;
    Server::new(acceptor).serve(router).await;
}

#[get("/articles/<id>")]
async fn article(db: &State<Db>, id: u64) -> Option<Json<Article>> {
    db.find(id).await.map(Json)
}

#[launch]
async fn rocket() -> _ {
    rocket::build()
        .manage(Db::connect().await)
        .mount("/", routes![article])
}

#[get("/articles/{id}")]
async fn article(db: web::Data<Db>, id: web::Path<u64>) -> impl Responder {
    match db.find(id.into_inner()).await {
        Some(a) => HttpResponse::Ok().json(a),
        None => HttpResponse::NotFound().finish(),
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let db = web::Data::new(Db::connect().await);
    HttpServer::new(move || App::new().app_data(db.clone()).service(article))
        .bind(("0.0.0.0", 3000))?
        .run()
        .await
}

The others, worth knowing

Before adopting a tool outside this list, check three things: the date of its last release, the number of people who merge contributions, and what you have to implement to write a middleware layer.

Downloads lie a little

That leaves the question everyone asks: which one is used the most? crates.io publishes each crate’s download count over the last ninety days. The result looks clear-cut, at first glance:

These figures measure the ecosystem more than the choice. tonic, the gRPC framework, bundles axum by default, and accounts for 102.7 million downloads on its own; the meta-frameworks bundle it too. Take out all of tonic, which overstates the correction, and about 41 million remain, more than three times Actix Web. The gap is real, but smaller than it looks. Above all, it says that axum has become infrastructure, not just a framework.

The cards start from the candidates; the compass goes the other way. It starts from your project, asks four questions and suggests a starting point: a framework, an alternative, and the [dependencies] block of your Cargo.toml. It doesn’t replace the reasoning of the previous parts: it sums it up.

Play with the answers: the framework line changes from one case to the next, the foundations almost never do. That’s exactly what part 2 said.

If you were to keep only one page of this article, it would be this one.

1. In Rust, the foundations do most of the work

   The runtime, the HTTP server, the middleware: tokio, hyper and tower provide them to almost everyone. The framework is just a thin layer on top.

2. The criterion that matters most: distance

   The more a framework replaces these foundations with its own, the more it does things its own way, the less it inherits from the ecosystem, and the more leaving it costs. Its middleware model tells you so in one line.

3. The smallest distance that is enough for you

   List what the foundations don’t give you, choose what you want to hand over to the framework, take the closest tool that covers all of it, and keep your business logic sheltered.

The file, once filled in

Here, concretely, is my default starting point. It’s the Cargo.toml of my-api, empty at the start of the article, once filled in:

[dependencies]
# The foundations (part 2): they almost never change.
tokio = { version = "1", features = ["full"] }
serde = { version = "1", features = ["derive"] }
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }

# The framework (part 5): one line, and it can be replaced.
axum = "0.8"
tower-http = { version = "0.7", features = ["trace", "cors", "compression-gzip"] }

# My building blocks (part 3): what an integrated framework would have chosen for me.
sqlx = { version = "0.9", features = ["runtime-tokio", "postgres"] }
utoipa = "6"
thiserror = "2"

Look where the framework is: one line out of nine. The rest are foundations you would keep with any other choice, and building blocks you chose yourself. That’s why none is the obvious choice: the real choice happens beneath the framework. In Rust, your framework isn’t one line of this file. It’s the whole file.

What I’m watching

Your turn

I’ve only given my reading, and my preferences. I’d love to hear yours.