Deze keuze is geen absoluut oordeel over de twee raamwerken. Het is een architectonisch compromis, hier gedocumenteerd met wat we hebben geverifieerd in de code en in openbare registers – niet met een ongemeten prestatiecijfer.
De essentie
Axum bouwt niets eigens: het vertrouwt op tower::Service voor zijn middleware, op Hyper voor transport, en verbiedt elke unsafe-code. Actix-web integreert zijn eigen middleware-systeem (Logger, Session, CORS), native HTTP/2, en noemt zelf de TechEmpower Framework Benchmark als bewijs van snelheid. Op kratten.io heeft Axum vandaag meer dan 436 miljoen downloads, vergeleken met ongeveer 78 miljoen voor Actix-web - ondanks een leeftijdsverschil van bijna vier jaar in zijn nadeel. Aurabase koos Axum voor de Tower-compositie, geverifieerd in elf echte Cargo.toml-repository's, niet voor een ongemeten prestatiecijfer.
Twee raamwerken, dezelfde Tokio-basis
Axum en Actix-web draaien beide op Tokio, de referentie-asynchrone runtime in Rust. De README van Actix-web stelt dit ronduit – “Volledige Tokio-compatibiliteit” – en het officiële codevoorbeeld gebruikt geen enkele actor uit het historische actix-framework: een klassieke async fn-handler, geannoteerd #[get(...)], is voldoende. De verwarring “Actix-web heeft noodzakelijkerwijs actoren nodig” komt niet langer overeen met de huidige API.
Axum werd geboren in de directe omgeving van Tokio: de repository is eigendom van de GitHub-organisatie tokio-rsen de officiële documentatie is ondubbelzinnig: "Axum is ontworpen om met tokio en hyper te werken. Onafhankelijkheid van runtime en transportlagen is geen doel, althans voorlopig. "
Het is dus geen keuze tussen twee concurrerende runtimes, maar tussen twee manieren om een HTTP API bovenop dezelfde asynchrone engine te bouwen. Deze vergelijking bestrijkt vier verifieerbare gebieden – middlewaremodel, gedeclareerde geheugenbeveiliging, native HTTP-oppervlak, acceptatie gemeten op kratten.io en GitHub – en legt vervolgens, met ondersteunende code, uit waarom de Rust-kern van Aurabase voor Axum koos.
Composeerbare middleware-toren versus geïntegreerd systeem
Axum bouwt geen eigen middlewaresystemen. Het vertrouwt volledig op tower::Service: time-outs, tracering, compressie, autorisatie – alles komt “gratis” via het Tower-ecosysteem, volgens zijn eigen README. Middleware geschreven voor een Hyper- of Tonic-applicatie kan zonder aanpassing hergebruikt worden zoals in een Axum-applicatie.
Actix-web volgt het tegenovergestelde pad: het integreert zijn eigen middleware-systeem (Logger, Session, CORS, etc.), gedocumenteerd in de gebruikershandleiding, met zijn eigen bijbehorende HTTP-client (awc). Het is een meer geïntegreerd platform – minder onderdelen om te assembleren, maar ook minder direct hergebruik met de rest van het generieke Rust asynchrone ecosysteem.
Routing volgt dezelfde expliciete compositielogica. Axum claimt een “macro-vrije API” voor het declareren van routes – Router::new().route(...) blijft een gewone Rust-waarde – waarbij Actix-web vertrouwt op speciale macro’s via de HTTP-methode (#[get(...)]) die direct boven de handler zijn geplaatst. Twee statement-stijlen, geen verschil in vaardigheid.
Aan de configureerbaarheid van Axum zijn kosten verbonden: u moet tower-http toevoegen om CORS, compressie of beperking van de querygrootte te verkrijgen, terwijl Actix-web deze intern levert. Out-of-the-box integratie versus expliciete compositie: een echte afweging, geen fout aan één kant.
Nul onveilig verklaard, twee verschillende MSRV’s
Axum claimt #![forbid(unsafe_code)] in de broncode: 100% van het raamwerk is geschreven in het veilige Rust, zonder mazen in de wet. Actix-web doet geen gelijkwaardige verklaring in zijn README – dit betekent niet dat het raamwerk gevaarlijk is, alleen dat een dergelijke garantie niet publiekelijk door het project wordt getoond.
De twee frameworks stellen een verschillende minimumversie van Rust in: Axum is compatibel vanaf Rust 1.80, Actix-web vereist Rust 1.88. Een smaller venster voor Actix-web, wat van belang kan zijn als uw toolchain vastloopt op een oudere versie.
Wat iedereen standaard verzendt
Actix-web vermeldt een groot HTTP-oppervlak rechtstreeks in zijn krat: HTTP/1.x en HTTP/2, WebSockets, transparante compressie (br, gzip, deflate, zstd), TLS via OpenSSL of Rustls. Alles komt samen, zonder extra afhankelijkheden waaruit u kunt kiezen.
Axum blijft bewust minimaal: routing, extractors, foutafhandeling – de rest (compressie, CORS, verzoekbeperking, tracering) komt van tower-http, een begeleidend krat uit hetzelfde ecosysteem. Aurabase schakelt bijvoorbeeld alleen de functies cors, trace, compression-gzip, request-id, timeout en limit van tower-http in – een bewuste selectie, niet het hele pakket.
Wat we kunnen controleren en wat we niet opnieuw publiceren
Actix-web claimt zijn snelheid door een precieze externe bron te citeren: “Een van de snelste webframeworks die beschikbaar zijn volgens de TechEmpower Framework Benchmark” (ronde r21, samengesteld), met een directe link naar techempower.com in zijn eigen README. Dit is het type offerte dat u zelf kunt verifiëren.
Axum maakt geen vergelijkbare bewering. De README ervan is beperkt tot een meer bescheiden verklaring – “axum is een relatief dunne laag bovenop hyper en voegt heel weinig overhead toe” – met twee links naar benchmarks van derden, en geen officieel projectcijfer.
Aurabase publiceert momenteel geen gekwantificeerde vergelijking van Axum versus Actix-web op basis van zijn eigen productielast. Een getal dat we niet zelf hebben gemeten, zal hier nooit opnieuw worden gepubliceerd als productargument – zie onze reproduceerbare benchmarkmethodologie, precies gebouwd om een verifieerbare methode te publiceren in plaats van een kaal getal.
Wat krates.io en GitHub zeggen, op het moment van schrijven
Op krates.ioheeft Axum in totaal 436.464.896 downloads, inclusief 109.000.226 gedurende de afgelopen 90 dagen. Actix-web verzamelt in totaal 78.074.020 downloads, inclusief 9.730.975 in hetzelfde recente venster (crates.io, geraadpleegd op 23 augustus 2026). Op dit punt is de kloof duidelijk: Axum ontvangt vandaag ongeveer 11 keer meer recente downloads dan Actix-web.
De paradox: Actix-web is de oudste van de twee, gepubliceerd op kratten.io sinds oktober 2017, vergeleken met juli 2021 voor Axum. Op GitHub is de kloof in populariteit kleiner: 26.931 sterren voor tokio-rs/axum tegen 24.793 voor actix/actix-web (GitHub, geraadpleegd op 23 augustus 2026) – en Actix-web heeft meer forks (1.880 vergeleken met 1.462), een teken dat er nog steeds een historische bijdragersbasis actief is.
Actix-web is nog lang niet verlaten: versie 4.15.0 werd gepubliceerd op 21 augustus 2026, drie dagen vóór het schrijven van dit artikel. Op de GitHub-uitgavewachtrij toont Axum 75 open tickets vergeleken met 192 voor Actix-web – een onderhoudssignaal dat met voorzichtigheid moet worden gelezen: een geschiedenis die bijna vier jaar langer is, mechaniseert een langere wachtrij, dit is geen bewijs van een minder zorgvuldig project.
Axum's README waarschuwt zelf dat zijn main branch een versie 0.9 aan het voorbereiden is met belangrijke wijzigingen - de stabiele branch gepubliceerd op kratten.io blijft 0.8.x. Als je vandaag begint, zet dan de exacte versie vast in plaats van de standaardvertakking van de repository te volgen.
Waarom Axum, geverifieerd in code
De Aurabase root Cargo werkruimte heeft elf services. Tien daarvan vertrouwen rechtstreeks op Axum – van de API-gateway (aura-gateway) tot denative AI-engine (aura-ai), inclusief authenticatie en opslag. De elfde, aura-migrator, is een CLI-migratietool zonder HTTP-server: er is simpelweg niets om uit te kiezen. Geen Cargo.toml in de repository – noch enig item in de root Cargo.lock – declareert actix-web, zelfs in transitieve afhankelijkheid; en geen enkel .rs-bestand bevat de use actix_web::-instructie.
Deze keuze is niet cosmetisch: de Aurabase-gateway (aura-gateway) stapelt zijn middleware op met tower::ServiceBuilder en Layer Tower — TraceLayer, TimeoutLayer, RequestBodyLimitLayer — aangevuld met interne lagen via axum::middleware::from_fn voor verzoekidentificatie, authenticatie en beveiligingsheaders. Dit is precies het compositiemodel dat Axum's README benadrukt: een Tower-middleware wordt onafhankelijk van de rest van de router gestapeld, getest en hergebruikt.
Wat hier wordt geverifieerd is de gekozen architectuur: de werkelijke afhankelijkheid, de werkelijke samenstelling van de middlewares. Er wordt geen gekwantificeerde prestatiewinst geclaimd: zie het vorige gedeelte over wat we niet opnieuw publiceren.
Axum en Actix-web naast elkaar
| Middelware | Samenstelling toren::Service, niets eigen | Geïntegreerd systeem (Logger, Sessie, CORS) |
|---|---|---|
| Geheugenbeveiliging | verbieden(onveilige_code) verklaard | Geen gelijkwaardige verklaring |
| MSRV | Roest 1,80 | Roest 1,88 |
| Licentie | MIT | Apache-2.0 OF MIT |
| Native HTTP | Routing + afzuigsystemen; de rest via toren-http | HTTP/1.x, HTTP/2, compressie, geïntegreerde TLS |
| kratten.io downloads (totaal) | 436 464 896 | 78 074 020 |
| Downloads kratten.io (90 dagen) | 109 000 226 | 9 730 975 |
| GitHub-sterren | 26 931 | 24 793 |
| Op kratten.io sinds | Juli 2021 | Oktober 2017 |
| Gebruikt door Aurabase | Ja - 10 van 11 Rust-services | Nee – geen afhankelijkheden, direct of transitief |
Bronnen: kratten.io API (/api/v1/crates/axum, /api/v1/crates/actix-web) en GitHub API, geraadpleegd op 23 augustus 2026. Officiële READMEs tokio-rs/axum en actix/actix-web voor de rest.
Wie moet wat kiezen
Je start een modulaire, multi-service Rust-backend. Axum past daar perfect bij: de Tower-samenstelling maakt het gemakkelijker om middleware tussen services te delen, zoals Aurabase dat doet tussen zijn tien HTTP-services.
U beschikt over een bestaande en werkende Actix-webcodebasis. Er is geen haast om te migreren. Actix-web blijft actief onderhouden en omvat native HTTP/2, WebSockets en compressie, zonder extra afhankelijkheden.
U wilt zoveel mogelijk HTTP-functionaliteit in één krat, zonder zelf tower-http in elkaar te zetten. Actix-web speelt direct in op deze behoefte.
Je deelt Tower-middleware al met andere Hyper- of Tonic-services (gRPC). Axum hergebruikt deze lagen zoals ze zijn – dit is het argument dat bij Aurabase doorslaggevend was.