Rust per il Web: Actix Web vs Axum – Confronto e domande da colloquio 2026

Rust si è affermato come linguaggio di riferimento per lo sviluppo di servizi web ad alte prestazioni, combinando la sicurezza della memoria garantita a compile-time con velocità paragonabili al C++. Nel panorama dei framework web Rust, due soluzioni dominano il mercato nel 2026: Actix Web e Axum. Entrambi offrono prestazioni eccezionali, ma differiscono significativamente nell'architettura, nell'ecosistema e nella filosofia di design. Questa guida analizza in profondità le differenze tra i due framework, fornendo esempi pratici e preparando i candidati alle domande più frequenti nei colloqui tecnici.

Differenze architetturali tra Actix Web e Axum

La distinzione fondamentale tra Actix Web e Axum risiede nel modello di runtime e nella gestione della concorrenza. Actix Web utilizza un sistema di attori leggeri derivato dal framework Actix, mentre Axum si basa interamente sull'ecosistema Tokio senza astrazioni aggiuntive.

Actix Web implementa un pattern actor-based dove ogni worker thread gestisce un event loop indipendente. Questa architettura consente un isolamento naturale dello stato e una gestione efficiente delle connessioni concorrenti:

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 adotta un approccio differente, costruendo direttamente sopra Tokio e la libreria Hyper per la gestione HTTP. Il framework utilizza il type system di Rust in modo estensivo per garantire la correttezza delle route a compile-time:

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();
}

La differenza nell'entry point risulta evidente: Actix Web utilizza la macro #[actix_web::main] che configura il proprio runtime, mentre Axum si appoggia direttamente a #[tokio::main]. Questa distinzione ha implicazioni pratiche nella composizione con altre librerie dell'ecosistema Tokio.

Benchmark delle prestazioni: Actix Web 4.13 vs Axum 0.8

I benchmark rappresentano un aspetto cruciale nella scelta del framework per applicazioni ad alto carico. Le misurazioni seguenti derivano da test condotti su hardware standardizzato con configurazioni ottimizzate per entrambi i framework:

| Metrica | Actix Web 4.13 | Axum 0.8.9 | |---------|---------------|-------------| | Serializzazione JSON (req/s) | ~720.000 | ~640.000 | | Plaintext (req/s) | ~980.000 | ~870.000 | | Query DB singola (req/s) | ~180.000 | ~170.000 | | Utilizzo memoria (hello world) | ~8 MB | ~6 MB | | Latenza P99 (JSON) | 1,2 ms | 1,4 ms |

Actix Web mantiene un vantaggio prestazionale del 10-15% negli scenari di throughput puro, attribuibile all'ottimizzazione specifica del proprio runtime per workload HTTP specifici. Axum compensa con un footprint di memoria leggermente inferiore e una latenza che rimane competitiva per la maggior parte delle applicazioni production.

È fondamentale contestualizzare questi numeri: entrambi i framework superano ampiamente le necessità del 99% delle applicazioni web. La differenza di 80.000 richieste al secondo raramente costituisce il collo di bottiglia in architetture reali, dove database, servizi esterni e logica applicativa dominano i tempi di risposta.

Extractors e gestione delle richieste a confronto

Gli extractors rappresentano il meccanismo principale per accedere ai dati delle richieste HTTP in entrambi i framework. Axum 0.8 ha introdotto significative modifiche alla sintassi degli extractors, rendendo il codice più esplicito e type-safe:

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 utilizza un sistema di extractors concettualmente simile ma con una sintassi differente, dove i tipi wrapper come web::Path e web::Query incapsulano i dati estratti:

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
    }))
}

La differenza principale risiede nella gestione dello stato: Actix Web utilizza web::Data<T> con clonazione automatica, mentre Axum richiede esplicitamente Arc<T> per lo stato condiviso, rendendo più visibile il costo della condivisione tra thread.

Architettura middleware: Tower vs Actix Middleware

L'architettura middleware costituisce uno degli aspetti più distintivi tra i due framework. Axum adotta Tower come standard per la composizione di middleware, beneficiando di un ecosistema consolidato di componenti riutilizzabili:

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())
}

Tower middleware offre vantaggi significativi in termini di riutilizzo: componenti come CorsLayer, CompressionLayer e TraceLayer funzionano con qualsiasi servizio Tower-compatible, non solo Axum. Questa interoperabilità risulta particolarmente vantaggiosa in architetture che combinano diversi servizi Rust.

Actix Web implementa un sistema di middleware proprietario basato sul trait Transform. Sebbene più potente in alcuni scenari specifici, richiede maggiore boilerplate per middleware personalizzati e non beneficia della stessa portabilità cross-framework.

Integrazione database con SQLx

SQLx rappresenta la libreria di riferimento per l'accesso database in Rust, offrendo query validate a compile-time contro uno schema database reale. L'integrazione con entrambi i framework risulta sostanzialmente identica, dato che SQLx opera a livello di pool di connessioni indipendente dal framework HTTP:

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
}

La validazione compile-time delle query SQL costituisce un vantaggio distintivo dell'ecosistema Rust: errori di sintassi SQL, tipi non corrispondenti e colonne mancanti vengono rilevati durante la compilazione anziché a runtime. Questa caratteristica elimina un'intera categoria di bug che affliggono applicazioni in altri linguaggi.

Gestione degli errori a confronto

La gestione degli errori in Axum si basa sul trait IntoResponse, permettendo di convertire tipi di errore custom direttamente in risposte HTTP. Questo pattern consente una gestione centralizzata e type-safe degli errori applicativi:

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 utilizza un approccio basato sul trait ResponseError, concettualmente simile ma con convenzioni differenti. Entrambi i framework supportano l'uso di anyhow o thiserror per la gestione degli errori, sebbene Axum richieda implementazioni IntoResponse esplicite per i tipi di errore custom.

Quando scegliere Actix Web

Actix Web rappresenta la scelta ottimale in scenari specifici dove le sue caratteristiche distintive offrono vantaggi concreti. Il framework eccelle nei seguenti contesti:

Le applicazioni che richiedono le massime prestazioni assolute beneficiano dell'ottimizzazione specifica di Actix Web per workload HTTP. In scenari dove ogni millisecondo conta, il vantaggio del 10-15% nel throughput può tradursi in risparmi infrastrutturali significativi.

I progetti che necessitano di WebSocket avanzati o streaming bidirezionale trovano in Actix Web un supporto maturo e ben documentato. Il modello actor-based si presta naturalmente alla gestione di connessioni persistenti.

I team con esperienza pregressa nel pattern actor o provenienti da ecosistemi come Erlang/Elixir apprezzeranno la familiarità concettuale del modello Actix.

Le applicazioni enterprise con requisiti di stabilità a lungo termine beneficiano della maturità di Actix Web, presente nell'ecosistema Rust da più tempo rispetto ad Axum.

Quando scegliere Axum

Axum si distingue come scelta preferibile in contesti dove l'integrazione con l'ecosistema Tokio e la modularità risultano prioritarie:

I progetti che utilizzano estensivamente altre librerie Tokio (tonic per gRPC, sqlx, reqwest) beneficiano dell'integrazione nativa di Axum, evitando potenziali conflitti di runtime.

Le architetture che richiedono middleware riutilizzabili tra diversi servizi traggono vantaggio dall'adozione di Tower come standard comune.

I team che preferiscono API minimali e composabili apprezzeranno l'approccio "less magic" di Axum, dove il comportamento risulta più prevedibile e debuggabile.

I progetti greenfield nel 2026 potrebbero preferire Axum per il momentum crescente e l'allineamento con la direzione dell'ecosistema Rust async.

Domande da colloquio: Actix Web e Axum

Le seguenti domande rappresentano quesiti frequenti nei colloqui tecnici per posizioni che richiedono competenze in web development Rust:

D: Qual è la differenza fondamentale tra il runtime di Actix Web e quello di Axum?

R: Actix Web utilizza un runtime custom basato su attori leggeri, dove ogni worker thread gestisce un event loop indipendente. Axum si basa interamente su Tokio senza astrazioni aggiuntive. Questa differenza influenza l'interoperabilità con altre librerie: Axum compone naturalmente con l'ecosistema Tokio, mentre Actix Web richiede attenzione nella gestione di futures Tokio all'interno dei suoi handler.

D: Come si implementa lo stato condiviso tra handler in Axum rispetto ad Actix Web?

R: In Axum lo stato condiviso richiede esplicitamente Arc<T> e viene iniettato tramite l'extractor State. In Actix Web si utilizza web::Data<T> che gestisce internamente la clonazione. La differenza rende più visibile in Axum il costo della condivisione thread-safe.

D: Perché Axum 0.8 ha cambiato la sintassi dei path parameters da /:id a /{id}?

R: Il cambiamento allinea Axum allo standard OpenAPI per la definizione dei path parameters, migliorando l'interoperabilità con strumenti di documentazione e generazione codice. La sintassi con parentesi graffe risulta anche più consistente con altri framework web in diversi linguaggi.

D: Come gestisce Axum la conversione degli errori in risposte HTTP?

R: Axum utilizza il trait IntoResponse per convertire qualsiasi tipo in una risposta HTTP. Per la gestione degli errori, si implementa IntoResponse per un enum di errori applicativi, mappando ogni variante al corrispondente status code e body JSON.

D: Qual è il vantaggio principale di Tower middleware rispetto al sistema middleware di Actix Web?

R: Tower middleware sono riutilizzabili tra qualsiasi servizio Tower-compatible, non solo Axum. Questo consente di condividere componenti middleware tra server HTTP, client gRPC e altri servizi. Actix middleware sono specifici del framework e non portabili.

Conclusioni

La scelta tra Actix Web e Axum nel 2026 dipende da fattori specifici del progetto e del team:

• Prestazioni pure: Actix Web mantiene un vantaggio del 10-15%, rilevante solo per applicazioni ad altissimo throughput
• Ecosistema Tokio: Axum offre integrazione nativa superiore con tonic, sqlx e altre librerie Tokio
• Middleware: Tower (Axum) garantisce riutilizzabilità cross-framework; Actix middleware rimangono framework-specific
• Curva di apprendimento: Axum risulta più accessibile per sviluppatori familiari con Tokio; Actix Web richiede comprensione del modello actor
• Maturità: Actix Web vanta una storia più lunga; Axum ha raggiunto stabilità completa con la versione 0.8
• Gestione errori: Entrambi offrono pattern type-safe; IntoResponse di Axum risulta leggermente più ergonomico
• Database: SQLx funziona identicamente con entrambi i framework, validando query a compile-time

Entrambi i framework rappresentano soluzioni production-ready capaci di gestire carichi significativi. La decisione finale dovrebbe considerare l'ecosistema esistente, le competenze del team e i requisiti specifici di performance e integrazione del progetto.