Esta escolha não constitui um julgamento absoluto sobre os dois enquadramentos. É um compromisso arquitetônico, documentado aqui com o que verificamos no código e nos registros públicos — e não com um valor de desempenho não medido.
O essencial
Axum não constrói nada proprietário: ele depende de tower::Service para seu middleware, de Hyper para transporte e proíbe qualquer código unsafe. Actix-web incorpora seu próprio sistema de middleware (Logger, Session, CORS), HTTP/2 nativo e cita o TechEmpower Framework Benchmark como prova de velocidade. No crates.io, o Axum tem hoje mais de 436 milhões de downloads, em comparação com cerca de 78 milhões do Actix-web - apesar da diferença de idade de quase quatro anos em sua desvantagem. Aurabase escolheu Axum para composição de Torre, verificada em onze repositórios Cargo.toml reais, não por um valor de desempenho não medido.
Dois frameworks, a mesma base Tokio
Axum e Actix-web rodam no Tokio, o tempo de execução assíncrono de referência no Rust. O README do Actix-web afirma isso sem rodeios - “Compatibilidade total com o Tokio” - e seu exemplo de código oficial não usa nenhum ator da estrutura histórica actix: um manipulador clássico async fn, anotado #[get(...)], é suficiente. A confusão “Actix-web requer necessariamente atores” não corresponde mais à API atual.
Axum nasceu na órbita direta de Tóquio: o repositório pertence à organização GitHub tokio-rs, e sua documentação oficial é inequívoca - "axum foi projetado para funcionar com tokio e hyper. A independência do tempo de execução e da camada de transporte não é um objetivo, pelo menos por enquanto. »
Portanto, não é uma escolha entre dois tempos de execução concorrentes, mas entre duas maneiras de construir uma API HTTP sobre o mesmo mecanismo assíncrono. Esta comparação cobre quatro áreas verificáveis – modelo de middleware, segurança de memória declarada, superfície HTTP nativa, adoção medida em crates.io e GitHub – e então explica, com código de suporte, por que o núcleo Rust do Aurabase escolheu Axum.
Torre Composable Middleware vs. Sistema Integrado
Axum não constrói nenhum sistema de middleware proprietário. Ele depende inteiramente de tower::Service: tempos limite, rastreamento, compactação, autorização — tudo vem “de graça” por meio do ecossistema Tower, de acordo com seu próprio README. Middleware escrito para uma aplicação Hyper ou Tonic pode ser reutilizado como está em uma aplicação Axum, sem adaptação.
Actix-web segue o caminho oposto: incorpora seu próprio sistema de middleware (Logger, Session, CORS, etc.), documentado em seu guia do usuário, com seu próprio cliente HTTP associado (awc). É uma plataforma mais integrada – menos peças para montar, mas também menos reutilização direta com o resto do ecossistema assíncrono Rust genérico.
O roteamento segue a mesma lógica de composição explícita. Axum afirma uma “API livre de macro” para declarar rotas – Router::new().route(...) permanece um valor Rust comum – onde Actix-web depende de macros dedicadas pelo método HTTP (#[get(...)]) colocadas diretamente acima do manipulador. Dois estilos de declaração, sem diferença de habilidade.
A capacidade de composição do Axum tem um custo: você deve adicionar tower-http para obter CORS, compactação ou limitação de tamanho de consulta, onde o Actix-web os entrega internamente. Integração pronta para uso versus composição explícita — uma verdadeira compensação, não uma falha unilateral.
Zero declarado inseguro, dois MSRVs diferentes
Axum afirma #![forbid(unsafe_code)] em seu código-fonte: 100% do framework é escrito em Rust seguro, sem brechas. Actix-web não faz uma declaração equivalente em seu README – isso não significa que a estrutura seja perigosa, apenas que tal garantia não é exibida publicamente pelo projeto.
Os dois frameworks definem uma versão mínima diferente do Rust: Axum é compatível com Rust 1.80, Actix-web requer Rust 1.88. Uma janela mais estreita para o Actix-web, o que pode ser importante se o seu conjunto de ferramentas estiver preso em uma versão mais antiga.
O que cada um envia nativamente
Actix-web lista uma grande superfície HTTP diretamente em sua caixa: HTTP/1.x e HTTP/2, WebSockets, compactação transparente (br, gzip, deflate, zstd), TLS via OpenSSL ou Rustls. Tudo vem junto, sem dependências adicionais para escolher.
Axum permanece deliberadamente mínimo: roteamento, extratores, tratamento de erros — o resto (compressão, CORS, limitação de solicitação, rastreamento) vem de tower-http, uma caixa complementar do mesmo ecossistema. Aurabase, por exemplo, habilita apenas os recursos cors, trace, compression-gzip, request-id, timeout e limit de tower-http — uma seleção deliberada, não o pacote inteiro.
O que podemos verificar e o que não republicamos
Actix-web afirma sua velocidade citando uma fonte externa precisa: “Uma das estruturas web mais rápidas disponíveis de acordo com o TechEmpower Framework Benchmark” (rodada r21, composto), com um link direto para techempower.com em seu próprio README. Este é o tipo de cotação que você mesmo pode verificar.
Axum não faz nenhuma afirmação comparável. Seu README é limitado a uma declaração mais modesta – “axum é uma camada relativamente fina sobre o hiper e adiciona muito pouca sobrecarga” – com dois links para benchmarks de comunidades de terceiros, e não um número oficial do projeto.
Aurabase atualmente não publica nenhuma comparação quantificada de Axum versus Actix-web em sua própria carga de produção. Um número que não medimos nunca será republicado aqui como um argumento de produto - veja nossa metodologia de benchmark reproduzível , construída precisamente para publicar um método verificável em vez de um número simples.
O que crates.io e GitHub dizem, no momento em que este livro foi escrito
Em crates.io, Axum tem 436.464.896 downloads no total, incluindo 109.000.226 nos últimos 90 dias. Actix-web acumula 78.074.020 downloads no total, incluindo 9.730.975 na mesma janela recente (crates.io, acessado em 23 de agosto de 2026). Nesse ponto, a lacuna é clara: o Axum hoje recebe cerca de 11 vezes mais downloads recentes do que o Actix-web.
O paradoxo: Actix-web é o mais antigo dos dois, publicado em crates.io desde outubro de 2017, em comparação com julho de 2021 para Axum. No GitHub, a lacuna de popularidade é menor - 26.931 estrelas para tokio-rs/axum contra 24.793 para actix/actix-web (GitHub, acessado em 23 de agosto de 2026) — e o Actix-web mantém mais forks (1.880 em comparação com 1.462), um sinal de uma base histórica de contribuidores ainda ativa.
O Actix-web continua longe de ser abandonado: sua versão 4.15.0 foi publicada em 21 de agosto de 2026, três dias antes da redação deste artigo. Na fila de problemas do GitHub, Axum exibe 75 tickets abertos em comparação com 192 do Actix-web — um sinal de manutenção a ser lido com cautela: um histórico de quase quatro anos a mais mecaniza uma fila mais longa, isso não é prova de um projeto menos cuidadoso.
O próprio README da Axum avisa que seu branch main está preparando uma versão 0.9 com alterações significativas — o branch estável publicado em crates.io permanece 0.8.x. Se você está começando hoje, fixe a versão exata em vez de seguir o branch padrão do repositório.
Por que Axum, verificado em código
O espaço de trabalho raiz Cargo do Aurabase possui onze serviços. Dez dependem diretamente da Axum — desde o gateway de API (aura-gateway) até o mecanismo de IA nativo (aura-ai), incluindo autenticação e armazenamento. A décima primeira, aura-migrator, é uma ferramenta CLI de migração sem servidor HTTP: simplesmente não há nada para escolher. Nenhum Cargo.toml no repositório — nem qualquer entrada na raiz Cargo.lock — declara actix-web, mesmo em dependência transitiva; e nenhum arquivo .rs contém instrução use actix_web::.
Esta escolha não é cosmética: o gateway Aurabase (aura-gateway) empilha seu middleware com tower::ServiceBuilder e Layer Tower — TraceLayer, TimeoutLayer, RequestBodyLimitLayer — complementado por camadas internas via axum::middleware::from_fn para identificador de solicitação, autenticação e cabeçalhos de segurança. Este é exatamente o modelo de composição que o README da Axum destaca: um middleware em torre é empilhado, testado e reutilizado independentemente do resto do roteador.
O que se verifica aqui é a arquitetura escolhida — a dependência real, a composição real dos middlewares. Nenhum ganho de desempenho quantificado é reivindicado: consulte a seção anterior sobre o que não republicamos.
Axum e Actix-web, lado a lado
| Middleware | Torre de composição::Serviço, nada proprietário | Sistema integrado (Logger, Session, CORS) |
|---|---|---|
| Segurança de memória | proibir(unsafe_code) declarado | Nenhuma declaração equivalente |
| MSRV | Ferrugem 1,80 | Ferrugem 1,88 |
| Licença | MIT | Apache-2.0 OU MIT |
| HTTP nativo | Roteamento + extratores; o resto via torre-http | HTTP/1.x, HTTP/2, compactação, TLS integrado |
| downloads de crates.io (total) | 436 464 896 | 78 074 020 |
| Baixa crates.io (90 dias) | 109 000 226 | 9 730 975 |
| Estrelas do GitHub | 26 931 | 24 793 |
| Em crates.io desde | Julho de 2021 | Outubro de 2017 |
| Usado por Aurabase | Sim – 10 de 11 serviços Rust | Não - sem dependências, diretas ou transitivas |
Fontes: API crates.io (/api/v1/crates/axum, /api/v1/crates/actix-web) e API GitHub, acessado em 23 de agosto de 2026. READMEs oficiais tokio-rs/axum e actix/actix-web para o resto.
Quem deve escolher o quê
Você inicia um back-end Rust modular e multisserviço. Axum é uma escolha natural – sua composição em torre facilita o compartilhamento de middleware entre serviços, como o Aurabase faz entre seus dez serviços HTTP.
Você tem uma base de código Actix-web existente e funcional. Não há pressa para migrar. Actix-web permanece ativamente mantido e cobre HTTP/2, WebSockets e compactação nativamente, sem dependências adicionais.
Você deseja que o máximo possível de funcionalidade HTTP seja entregue em uma única caixa, sem montar tower-http você mesmo. Actix-web responde diretamente a esta necessidade.
Você já compartilha o middleware Tower com outros serviços Hyper ou Tonic (gRPC). Axum reutiliza essas camadas como estão – esse é o argumento que pesou na Aurabase.