Rust voor het Web: Actix Web vs Axum – Vergelijking en sollicitatievragen 2026

Het Rust-ecosysteem voor webontwikkeling heeft zich de afgelopen jaren sterk ontwikkeld, met twee frameworks die consequent bovenaan de benchmarks verschijnen: Actix Web en Axum. Beide frameworks bieden uitstekende prestaties en type-veiligheid, maar ze verschillen fundamenteel in architectuur en filosofie. Voor ontwikkelaars die overwegen Rust te gebruiken voor backend-services, en voor wie zich voorbereidt op technische sollicitatiegesprekken, is een grondig begrip van beide frameworks essentieel. Dit artikel analyseert de kernverschillen, vergelijkt prestaties met actuele benchmarks van 2026, en behandelt veelgestelde sollicitatievragen.

Architectuurverschillen tussen Actix Web en Axum

Actix Web is gebouwd rond het actor-model, oorspronkelijk geïmplementeerd met het Actix actor-framework. Hoewel moderne versies van Actix Web het actor-systeem optioneel maken, blijft de architectuur geoptimaliseerd voor hoge concurrency met minimale overhead. Het framework beheert zijn eigen runtime-abstracties en biedt een uitgebreide set ingebouwde functionaliteit.

use actix_web::{web, App, HttpServer, HttpResponse};

async fn health() -> HttpResponse {
    HttpResponse::Ok().json(serde_json::json!({ "status": "ok" }))
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/health", web::get().to(health))
    })
    .bind("0.0.0.0:8080")?
    .run()
    .await
}

Axum daarentegen is ontwikkeld door het Tokio-team en integreert naadloos met het Tower-ecosysteem. Het framework maakt geen gebruik van macro's voor routedefinities en vertrouwt volledig op Rust's type-systeem voor request-extractie. Deze aanpak resulteert in betere compileerfouten en eenvoudigere integratie met bestaande Tower-middleware.

use axum::{Router, Json, routing::get};
use serde_json::{json, Value};

async fn health() -> Json<Value> {
    Json(json!({ "status": "ok" }))
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/health", get(health));

    let listener = tokio::net::TcpListener::bind("0.0.0.0:8080")
        .await
        .unwrap();
    axum::serve(listener, app).await.unwrap();
}

De structurele verschillen worden direct zichtbaar in de bovenstaande voorbeelden. Actix Web vereist de #[actix_web::main] macro en retourneert std::io::Result, terwijl Axum de standaard #[tokio::main] macro gebruikt. Axum's Router is composeerbaar via method chaining, wat het combineren van subrouters vereenvoudigt.

Prestatiebenchmarks: Actix Web 4.13 vs Axum 0.8

Prestatiemetingen blijven een belangrijk criterium bij de keuze voor een webframework, hoewel het verschil tussen Actix Web en Axum in de praktijk zelden de beslissende factor vormt. Onderstaande benchmarks zijn uitgevoerd op identieke hardware met geoptimaliseerde release-builds.

| Meting | Actix Web 4.13 | Axum 0.8.9 | |--------|---------------|-------------| | JSON-serialisatie (req/s) | ~720.000 | ~640.000 | | Plaintext (req/s) | ~980.000 | ~870.000 | | DB-query enkel (req/s) | ~180.000 | ~170.000 | | Geheugengebruik (hello world) | ~8 MB | ~6 MB | | P99-latentie (JSON) | 1,2 ms | 1,4 ms |

Actix Web toont consistent hogere doorvoer in synthetische benchmarks, met name bij JSON-serialisatie waar het verschil ongeveer 12% bedraagt. Axum compenseert dit met lager geheugengebruik en biedt vergelijkbare prestaties bij database-gebonden workloads. Voor de meeste productieomgevingen zijn beide frameworks ruimschoots snel genoeg, en factoren zoals ontwikkelaarservaring en ecosysteemintegratie wegen zwaarder dan ruwe prestaties.

Extractors en request-handling vergeleken

Beide frameworks gebruiken het extractor-patroon om data uit inkomende requests te halen. Dit patroon maakt handlers declaratief en type-veilig, waarbij de compiler garandeert dat alle benodigde data correct wordt geëxtraheerd.

use axum::{
    extract::{Path, Query, State, Json},
    routing::get,
    Router,
};
use serde::Deserialize;
use std::sync::Arc;

#[derive(Deserialize)]
struct Pagination {
    page: Option<u32>,    // defaults to None if missing
    per_page: Option<u32>,
}

// State shared across handlers
struct AppState {
    db_pool: sqlx::PgPool,
}

// Axum 0.8: /{id} syntax (replaced /:id)
async fn get_user(
    State(state): State<Arc<AppState>>,
    Path(user_id): Path<i64>,
    Query(pagination): Query<Pagination>,
) -> Json<serde_json::Value> {
    let page = pagination.page.unwrap_or(1);
    // Query database using state.db_pool
    Json(serde_json::json!({
        "user_id": user_id,
        "page": page
    }))
}

Actix Web hanteert een vergelijkbare aanpak, maar met subtiele syntactische verschillen. De web::Data wrapper vervangt Axum's State, en path-parameters worden via web::Path geëxtraheerd.

use actix_web::{web, HttpResponse};
use serde::Deserialize;

#[derive(Deserialize)]
struct Pagination {
    page: Option<u32>,
    per_page: Option<u32>,
}

struct AppState {
    db_pool: sqlx::PgPool,
}

async fn get_user(
    state: web::Data<AppState>,
    path: web::Path<i64>,
    query: web::Query<Pagination>,
) -> HttpResponse {
    let user_id = path.into_inner();
    let page = query.page.unwrap_or(1);
    HttpResponse::Ok().json(serde_json::json!({
        "user_id": user_id,
        "page": page
    }))
}

Een fundamenteel verschil betreft de volgorde van extractors. In Axum is de volgorde van functie-parameters significant: State moet altijd als laatste komen wanneer gecombineerd met andere extractors die de request-body consumeren. Actix Web kent deze beperking niet en staat willekeurige parametervolgorde toe.

Middleware-architectuur: Tower vs Actix Middleware

De middleware-architectuur vormt een van de meest significante verschillen tussen beide frameworks. Axum bouwt volledig op Tower, een middleware-framework dat oorspronkelijk is ontwikkeld voor gRPC-services. Dit betekent dat elke Tower-middleware direct werkt met Axum, inclusief rate-limiting, tracing, compression en authentication-layers uit het bredere ecosysteem.

use axum::{
    Router, middleware,
    routing::get,
    extract::Request,
    response::Response,
};
use tower_http::{
    cors::CorsLayer,
    compression::CompressionLayer,
    trace::TraceLayer,
};
use std::time::Instant;

// Custom middleware as a plain async function
async fn timing_middleware(
    request: Request,
    next: middleware::Next,
) -> Response {
    let start = Instant::now();
    let response = next.run(request).await;
    let duration = start.elapsed();
    tracing::info!("Request took {:?}", duration);
    response
}

fn build_router() -> Router {
    Router::new()
        .route("/api/data", get(|| async { "ok" }))
        .layer(middleware::from_fn(timing_middleware))
        .layer(CompressionLayer::new())
        .layer(CorsLayer::permissive())
        .layer(TraceLayer::new_for_http())
}

Actix Web gebruikt zijn eigen middleware-systeem dat weliswaar krachtig is, maar minder herbruikbare componenten biedt dan Tower. Custom middleware in Actix Web vereist implementatie van de Transform en Service traits, wat meer boilerplate-code oplevert dan Axum's functionele aanpak.

Database-integratie met SQLx

SQLx is de de-facto standaard voor database-interactie in Rust-webapplicaties, en beide frameworks integreren uitstekend met deze library. SQLx biedt compile-time query-validatie tegen een live database, wat runtime-fouten door SQL-syntaxfouten of schema-mismatches elimineert.

use sqlx::PgPool;

// This struct works identically with Actix Web and Axum
#[derive(sqlx::FromRow, serde::Serialize)]
struct User {
    id: i64,
    email: String,
    created_at: chrono::NaiveDateTime,
}

// sqlx::query_as! validates against a live DB at compile time
async fn find_user_by_email(
    pool: &PgPool,
    email: &str,
) -> Result<Option<User>, sqlx::Error> {
    sqlx::query_as!(
        User,
        "SELECT id, email, created_at FROM users WHERE email = $1",
        email
    )
    .fetch_optional(pool)
    .await
}

De database-laag blijft volledig framework-agnostisch. Dezelfde repository-functies werken identiek in Actix Web en Axum, wat migratie tussen frameworks vereenvoudigt. Connection pooling via PgPool wordt in beide gevallen doorgegeven als gedeelde state, met web::Data in Actix Web of State in Axum.

Foutafhandeling vergeleken

Axum's benadering van foutafhandeling via de IntoResponse trait biedt elegante conversie van applicatiefouten naar HTTP-responses. Dit patroon moedigt het definiëren van een centrale AppError enum aan die alle mogelijke foutcondities omvat.

use axum::{
    http::StatusCode,
    response::{IntoResponse, Response},
    Json,
};

// Define application-level errors
enum AppError {
    NotFound(String),
    DatabaseError(sqlx::Error),
    ValidationError(String),
}

// Convert errors into HTTP responses
impl IntoResponse for AppError {
    fn into_response(self) -> Response {
        let (status, message) = match self {
            AppError::NotFound(msg) => (
                StatusCode::NOT_FOUND, msg
            ),
            AppError::DatabaseError(_) => (
                StatusCode::INTERNAL_SERVER_ERROR,
                "Internal server error".to_string(),
            ),
            AppError::ValidationError(msg) => (
                StatusCode::BAD_REQUEST, msg
            ),
        };
        (status, Json(serde_json::json!({ "error": message })))
            .into_response()
    }
}

// Handlers return Result<T, AppError>
async fn get_user(
    axum::extract::Path(id): axum::extract::Path<i64>,
) -> Result<Json<serde_json::Value>, AppError> {
    if id <= 0 {
        return Err(AppError::ValidationError(
            "ID must be positive".to_string()
        ));
    }
    Ok(Json(serde_json::json!({ "id": id })))
}

Actix Web hanteert een vergelijkbaar patroon via de ResponseError trait. Het belangrijkste verschil is dat Actix Web standaard meer gedetailleerde foutinformatie logt, terwijl Axum minimalistischer is en logging overlaat aan de ontwikkelaar via tracing-middleware.

Wanneer Actix Web kiezen

Actix Web is de juiste keuze in specifieke scenario's. Projecten die maximale doorvoer vereisen, met name bij JSON-zware API's, profiteren van Actix Web's geoptimaliseerde serialisatie. Bestaande codebases die al Actix Web gebruiken, rechtvaardigen zelden een migratie naar Axum gezien de beperkte prestatiewinst.

Teams met ervaring in het Actix-ecosysteem kunnen sneller itereren door bekendheid met de API. Daarnaast biedt Actix Web's ingebouwde WebSocket-ondersteuning een volwassener API dan Axum's huidige implementatie.

Wanneer Axum kiezen

Axum verdient de voorkeur voor nieuwe projecten zonder legacy-overwegingen. De integratie met het Tower-ecosysteem biedt toegang tot een breed scala aan herbruikbare middleware. Projecten die gRPC-services combineren met REST-API's profiteren van gedeelde middleware tussen Tonic en Axum.

De leesbaarheid van compileerfouten in Axum overtreft die van Actix Web, wat de ontwikkelaarservaring verbetert. Teams die waarde hechten aan moderne API-design en sterke type-veiligheid zonder macro-magie vinden in Axum een prettige werkomgeving.

Sollicitatievragen: Actix Web en Axum

Technische sollicitatiegesprekken voor Rust-webontwikkeling richten zich vaak op fundamentele concepten die beide frameworks delen, evenals framework-specifieke kennis.

Vraag: Leg uit hoe het extractor-patroon werkt in Axum en waarom parametervolgorde belangrijk is.

Het extractor-patroon in Axum gebruikt Rust's type-systeem om request-data automatisch te deserialiseren naar functie-parameters. Elke extractor implementeert de FromRequest of FromRequestParts trait. Parametervolgorde is cruciaal omdat sommige extractors (zoals Json) de request-body consumeren. Na consumptie is de body niet meer beschikbaar voor volgende extractors. State moet daarom als laatste komen wanneer gecombineerd met body-consumerende extractors.

Vraag: Wat zijn de voordelen van Tower-middleware boven Actix's middleware-systeem?

Tower-middleware is herbruikbaar tussen verschillende frameworks in het Rust-ecosysteem, waaronder Axum, Tonic en Hyper. Dit betekent dat middleware geschreven voor gRPC-services direct werkt voor HTTP-services. Tower's Service trait is composeerbaar en testbaar, met een rijke set bestaande middleware in tower-http.

Vraag: Hoe garandeert SQLx type-veiligheid bij compile-time?

SQLx valideert queries tegen een live database tijdens compilatie. De query_as! macro parseert de SQL-string, verbindt met de database gespecificeerd in DATABASE_URL, en verifieert dat kolommen bestaan en types overeenkomen met de Rust-struct. Dit elimineert runtime-fouten door typefouten in kolomnamen of incompatibele types.

Vraag: Beschrijf hoe graceful shutdown werkt in Axum.

Axum's serve functie accepteert een with_graceful_shutdown modifier die een future ontvangt. Wanneer deze future resolvet, stopt de server met het accepteren van nieuwe connecties en wacht tot bestaande requests zijn afgerond. Typisch wordt een tokio::signal::ctrl_c() future gebruikt om SIGINT te vangen.

Conclusie

De keuze tussen Actix Web en Axum hangt af van projectvereisten en teamvoorkeuren.

• Prestaties: Actix Web leidt met ~12% hogere doorvoer in JSON-benchmarks, maar beide frameworks overtreffen de meeste praktische vereisten ruimschoots
• Ecosysteem: Axum's Tower-integratie biedt toegang tot meer herbruikbare middleware en betere interoperabiliteit met Tonic voor gRPC
• Leercurve: Axum's foutmeldingen zijn duidelijker en de API voelt idiomatischer voor Rust-ontwikkelaars
• Stabiliteit: Actix Web heeft een langere track record in productie, terwijl Axum sneller evolueert met breaking changes tussen minor versions
• Database-integratie: Beide frameworks werken uitstekend met SQLx en andere database-libraries zonder framework-specifieke aanpassingen

Voor de meeste nieuwe projecten biedt Axum de beste balans tussen prestaties, ontwikkelaarservaring en ecosysteemintegratie. Bestaande Actix Web-projecten hebben zelden baat bij migratie.