Questa scelta non costituisce un giudizio assoluto sui due quadri. È un compromesso architetturale, documentato qui con ciò che abbiamo verificato nel codice e nei registri pubblici, non con un valore prestazionale non misurato.
L'essenziale
Axum non costruisce nulla di proprietario: si affida a tower::Service per il middleware, a Hyper per il trasporto e vieta qualsiasi codice unsafe. Actix-web incorpora il proprio sistema middleware (Logger, Session, CORS), HTTP/2 nativo, e cita esso stesso il TechEmpower Framework Benchmark come prova di velocità. Su crates.io Axum conta oggi più di 436 milioni di download rispetto ai circa 78 milioni di Actix-web, nonostante quasi quattro anni di differenza di età a suo svantaggio. Aurabase ha scelto Axum per la composizione della Tower, verificata in undici repository reali Cargo.toml, non per un dato prestazionale non misurato.
Due strutture, la stessa base di Tokio
Axum e Actix-web funzionano entrambi su Tokio, il runtime asincrono di riferimento in Rust. Il README di Actix-web lo afferma senza mezzi termini - "Compatibilità completa con Tokio" - e il suo esempio di codice ufficiale non utilizza alcun attore dello storico framework actix: un classico gestore async fn, annotato #[get(...)], è sufficiente. La confusione "Actix-web richiede necessariamente attori" non corrisponde più all'attuale API.
Axum è nato nell'orbita diretta di Tokyo: il repository appartiene all'organizzazione GitHub tokio-rse la sua documentazione ufficiale è inequivocabile: "axum è progettato per funzionare con Tokyo e Hyper. L'indipendenza dal runtime e dal livello di trasporto non è un obiettivo, almeno per il momento. »
Quindi non si tratta di una scelta tra due runtime concorrenti, ma tra due modi di creare un'API HTTP sullo stesso motore asincrono. Questo confronto copre quattro aree verificabili – modello middleware, sicurezza della memoria dichiarata, superficie HTTP nativa, adozione misurata su crates.io e GitHub – quindi spiega, con il codice di supporto, perché il core Rust di Aurabase ha scelto Axum.
Middleware Tower componibile vs. Sistema Integrato
Axum non realizza alcun sistema middleware proprietario. Si basa interamente su tower::Service: timeout, tracciamento, compressione, autorizzazione: tutto arriva "gratuitamente" tramite l'ecosistema Tower, secondo il proprio README. Il middleware scritto per un'applicazione Hyper o Tonic può essere riutilizzato così com'è in un'applicazione Axum, senza adattamenti.
Actix-web prende la strada opposta: incorpora il proprio sistema middleware (Logger, Session, CORS, ecc.), documentato nella sua guida per l'utente, con il proprio client HTTP associato (awc). È una piattaforma più integrata: meno parti da assemblare, ma anche un riutilizzo meno diretto con il resto dell'ecosistema asincrono Rust generico.
Il routing segue la stessa logica di composizione esplicita. Axum rivendica una "API priva di macro" per dichiarare i percorsi - Router::new().route(...) rimane un normale valore Rust - dove Actix-web si basa su macro dedicate tramite metodo HTTP (#[get(...)]) posizionate direttamente sopra il gestore. Due stili di affermazione, non una differenza di abilità.
La componibilità di Axum ha un costo: è necessario aggiungere tower-http per ottenere CORS, compressione o limitazione delle dimensioni delle query, laddove Actix-web li fornisce internamente. Integrazione immediata rispetto a composizione esplicita: un vero compromesso, non un difetto da un lato.
Zero dichiarato non sicuro, due MSRV diversi
Axum afferma #![forbid(unsafe_code)] nel suo codice sorgente: il 100% del framework è scritto in Rust sicuro, senza scappatoie. Actix-web non fa una dichiarazione equivalente nel suo README: questo non significa che il framework sia pericoloso, ma solo che nessuna garanzia del genere è pubblicamente mostrata dal progetto.
I due framework impostano una versione minima di Rust diversa: Axum è compatibile da Rust 1.80, Actix-web richiede Rust 1.88. Una finestra più ristretta per Actix-web, che potrebbe avere importanza se la tua toolchain è bloccata su una versione precedente.
Ciò che ciascuno spedisce in modo nativo
Actix-web elenca un'ampia superficie HTTP direttamente nella sua confezione: HTTP/1.x e HTTP/2, WebSocket, compressione trasparente (br, gzip, deflate, zstd), TLS tramite OpenSSL o Rustls. Tutto si unisce, senza dipendenze aggiuntive tra cui scegliere.
Axum rimane volutamente minimale: routing, estrattori, gestione degli errori: il resto (compressione, CORS, limitazione delle richieste, tracciamento) proviene da tower-http, un pacchetto complementare dello stesso ecosistema. Aurabase, ad esempio, abilita solo le funzionalità cors, trace, compression-gzip, request-id, timeout e limit di tower-http: una selezione deliberata, non l'intero pacchetto.
Cosa possiamo controllare e cosa non ripubblichiamo
Actix-web rivendica la sua velocità citando una precisa fonte esterna: “Uno dei framework web più veloci disponibili secondo il TechEmpower Framework Benchmark” (round r21, composite), con un collegamento diretto a techempower.com nel proprio README. Questo è il tipo di preventivo che puoi verificare tu stesso.
Axum non fa alcuna affermazione paragonabile. Il suo README si limita a un'affermazione più modesta - "axum è uno strato relativamente sottile sopra hyper e aggiunge pochissimo sovraccarico" - con due collegamenti a benchmark di comunità di terze parti, non una cifra ufficiale del progetto.
Aurabase attualmente non pubblica alcun confronto quantificato tra Axum e Actix-web sul proprio carico di produzione. Un numero che non abbiamo misurato noi stessi non verrà mai ripubblicato qui come argomento del prodotto: consulta la nostra metodologia di benchmark riproducibile , creata proprio per pubblicare un metodo verificabile anziché un semplice numero.
Cosa dicono crates.io e GitHub al momento della stesura di questo articolo
Su crates.io, Axum ha 436.464.896 download in totale, inclusi 109.000.226 negli ultimi 90 giorni. Actix-web accumula 78.074.020 download in totale, inclusi 9.730.975 nella stessa finestra recente (crates.io, accesso il 23 agosto 2026). Su questo punto il divario è evidente: Axum riceve oggi circa 11 volte più download recenti di Actix-web.
Il paradosso: Actix-web è il più vecchio dei due, pubblicato su crates.io da ottobre 2017, rispetto a luglio 2021 per Axum. Su GitHub, il divario di popolarità è più ristretto: 26.931 stelle per tokio-rs/axum contro 24.793 per actix/actix-web (GitHub, accesso il 23 agosto 2026) - e Actix-web mantiene più fork (1.880 rispetto a 1.462), segno di una base storica di contributori ancora attiva.
Actix-web resta lungi dall'essere abbandonato: la sua versione 4.15.0 è stata pubblicata il 21 agosto 2026, tre giorni prima della stesura di questo articolo. Sulla coda delle emissioni di GitHub, Axum mostra 75 ticket aperti rispetto ai 192 di Actix-web — un segnale di manutenzione da leggere con cautela: una storia più lunga di quasi quattro anni meccanizza una coda più lunga, questo non è la prova di un progetto meno attento.
Lo stesso README di Axum avverte che il suo ramo main sta preparando una versione 0.9 con modifiche importanti: il ramo stabile pubblicato su crates.io rimane 0.8.x. Se inizi oggi, aggiungi la versione esatta anziché seguire il ramo predefinito del repository.
Perché Axum, verificato in codice
L'area di lavoro root Aurabase Cargo dispone di undici servizi. Dieci si affidano direttamente ad Axum: dal gateway API (aura-gateway) al motore AI nativo (aura-ai), comprese l'autenticazione e l'archiviazione. L'undicesimo, aura-migrator, è uno strumento CLI di migrazione senza server HTTP: semplicemente non ha nulla da cui scegliere. Nessun Cargo.toml nel repository — né alcuna voce nella radice Cargo.lock — dichiara actix-web, anche in dipendenza transitiva; e nessun file .rs contiene l'istruzione use actix_web::.
Questa scelta non è cosmetica: il gateway Aurabase (aura-gateway) impila il suo middleware con tower::ServiceBuilder e Layer Tower — TraceLayer, TimeoutLayer, RequestBodyLimitLayer — integrati da livelli interni tramite axum::middleware::from_fn per identificatore di richiesta, autenticazione e intestazioni di sicurezza. Questo è esattamente il modello di composizione evidenziato dal README di Axum: un middleware Tower viene impilato, testato e riutilizzato indipendentemente dal resto del router.
Ciò che viene verificato qui è l'architettura scelta: la dipendenza reale, la composizione reale dei middleware. Non viene rivendicato alcun miglioramento delle prestazioni quantificato: vedere la sezione precedente su ciò che non ripubblichiamo.
Axum e Actix-web, fianco a fianco
| Middleware | Torre di composizione::Servizio, niente di proprietario | Sistema integrato (Logger, Sessione, CORS) |
|---|---|---|
| Sicurezza della memoria | forbid(unsafe_code) dichiarato | Nessuna dichiarazione equivalente |
| MSRV | Ruggine 1,80 | Ruggine 1.88 |
| Licenza | MIT | Apache-2.0 O MIT |
| HTTP nativo | Instradamento + estrattori; il resto tramite tower-http | HTTP/1.x, HTTP/2, compressione, TLS integrato |
| Download di crates.io (totale) | 436 464 896 | 78 074 020 |
| Download crates.io (90 giorni) | 109 000 226 | 9 730 975 |
| Stelle di GitHub | 26 931 | 24 793 |
| Su crates.io da allora | Luglio 2021 | ottobre 2017 |
| Utilizzato da Aurabase | Sì, 10 di 11 servizi Rust | No, nessuna dipendenza, diretta o transitiva |
Fonti: crates.io API (/api/v1/crates/axum, /api/v1/crates/actix-web) e GitHub API, accesso il 23 agosto 2026. README ufficiali tokio-rs/axum e actix/actix-web per il resto.
Chi dovrebbe scegliere cosa
Avvii un backend Rust modulare e multiservizio. Axum è una soluzione naturale: la sua composizione Tower semplifica la condivisione del middleware tra i servizi, come fa Aurabase tra i suoi dieci servizi HTTP.
Hai una base di codice Actix-web esistente e funzionante. Non c'è fretta di migrare. Actix-web rimane mantenuto attivamente e copre HTTP/2, WebSocket e compressione in modo nativo, senza dipendenze aggiuntive.
Desideri che venga fornita quanta più funzionalità HTTP possibile in un unico pacchetto, senza assemblare tower-http da solo. Actix-web risponde direttamente a questa esigenza.
Condividi già il middleware Tower con altri servizi Hyper o Tonic (gRPC). Axum riutilizza questi strati così come sono: questo è l'argomento che ha pesato su Aurabase.