Actix-web
Actix-web é um framework HTTP maduro e de alta performance com seu próprio modelo de runtime - uma forte alternativa ao Axum para equipes que o desejam.
Receita
Cartão de receita de referência rápida - pronto para copiar e colar.
use actix_web::{get, post, web, App, HttpResponse, HttpServer, Responder};
use serde::Deserialize;
#[derive(Deserialize)]
struct CreateItem { name: String }
#[get("/health")]
async fn health() -> impl Responder { "ok" }
#[post("/items")]
async fn create(body: web::Json<CreateItem>) -> HttpResponse {
HttpResponse::Created().json(serde_json::json!({ "name": body.name }))
}
#[actix_web::main]
async fn main() -> std::io::Result<()> {
HttpServer::new(|| App::new().service(health).service(create))
.bind(("127.0.0.1", 8080))?
.run()
.await
}Quando usar isso: Você precisa de um framework testado em batalha com extratores integrados, utilitários de teste e um grande ecossistema - e sua equipe se sente confortável fora da pilha apenas com Tower.
Exemplo de Trabalho
use actix_web::{delete, get, post, web, App, HttpResponse, HttpServer};
use serde::{Deserialize, Serialize};
use std::sync::Mutex;
#[derive(Serialize, Clone)]
struct Item { id: u64, name: String }
#[derive(Deserialize)]
struct NewItem { name: String }
struct AppState { items: Mutex<Vec<Item>> }
#[get("/items")]
async fn list(data: web::Data<AppState>) -> web::Json<Vec<Item>> {
web::Json(data.items.lock().unwrap().clone())
}
#[post("/items")]
async fn create(data: web::Data<AppState>, body: web::Json<NewItem>) -> HttpResponse {
let mut items = data.items.lock().unwrap();
let item = Item { id: items.len() as u64 + 1, name: body.name.clone() };
items.push(item.clone());
HttpResponse::Created().json(item)
}
#[delete("/items/{id}")]
async fn remove(data: web::Data<AppState>, path: web::Path<u64>) -> HttpResponse {
let mut items = data.items.lock().unwrap();
if let Some(pos) = items.iter().position(|i| i.id == *path) {
items.remove(pos);
HttpResponse::NoContent().finish()
} else {
HttpResponse::NotFound().finish()
}
}
#[actix_web::main]
async fn main() -> std::io::Result<()> {
let state = web::Data::new(AppState { items: Mutex::new(vec![]) });
HttpServer::new(move || {
App::new()
.app_data(state.clone())
.service(list)
.service(create)
.service(remove)
})
.bind(("127.0.0.1", 8080))?
.run()
.await
}O que isso demonstra:
- Macros de atributo
#[get],#[post]definem rotas em funções manipuladoras. web::Data<T>compartilha estado entre threads de worker.web::Jsonpara serialização de requisição e resposta.HttpServercria múltiplos workers para paralelismo.
Análise Profunda
Como Funciona
- Actix-web é construído sobre o sistema de atores Actix para concorrência (embora os manipuladores sejam assíncronos).
HttpServerclona a fábricaApppara cada thread de worker.- Extratores como
web::Path,web::Query,web::Jsonespelham a ergonomia do Axum.
Axum vs Actix-web
| Tópico | Axum | Actix-web |
|---|---|---|
| Ecossistema | Camadas Tower em todos os lugares | Middleware Actix |
| Estado | State<T> + Clone | web::Data<T> + Arc |
| Curva de aprendizado | Conceitos Tower | Documentação autônoma |
| Performance | Excelente | Excelente |
Notas de Rust
// Escopo de rotas sob um prefixo
use actix_web::web::scope;
App::new().service(scope("/api/v1").service(list).service(create));Armadilhas
- Mutex em manipuladores assíncronos -
std::sync::Mutexentre pontos deawaitpode causar deadlock. Correção: Usetokio::sync::Mutexou mantenha os escopos de lock curtos. - Clonagem da fábrica de App - Configuração cara na closure
HttpServer::newé executada por worker. Correção: Crieweb::Datacompartilhado fora da closure. - Mistura de runtimes - Bibliotecas que esperam Tokio puro podem precisar de adaptadores. Correção: Prefira crates nativos do Tokio (
sqlx,reqwest). - Modelo de middleware diferente - Camadas Tower não se encaixam diretamente. Correção: Use middleware
actix-webou faça proxy reverso. - Diferenças no cliente de teste - A API
TestRequestdifere dooneshotdo Axum. Correção: Padronize em um framework por serviço.
Alternativas
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Axum | Novos projetos que desejam a composabilidade do Tower | Equipe tem profundo conhecimento de Actix e código existente |
| Rocket | Prototipagem rápida com macros | Serviços de produção que necessitam de máxima escolha de ecossistema |
| warp | Pilhas legadas do hyper 0.14 | Projetos Greenfield |
FAQs
Actix ainda é mantido?
Sim - lançamentos ativos; amplamente utilizado em produção.
Atores Actix são necessários?
Não para manipuladores HTTP típicos - funções assíncronas são suficientes.
WebSockets no Actix?
actix-web-actors e actix-ws suportam upgrades.
sqlx com Actix?
Funciona via web::Data<PgPool> e manipuladores #[get].
Deploy atrás do nginx?
O mesmo que Axum - proxy reverso para a porta vinculada, passe os cabeçalhos X-Forwarded-*.
OpenAPI?
paperclip ou esquemas manuais - não integrado.
Desligamento gracioso?
HttpServer::run lida com sinais; configure o timeout para drenagem.
Migrar Actix para Axum?
Reescreva rotas e middleware; compartilhe crates de lógica de domínio inalterados.
Otimização de performance?
Combine o número de workers com os núcleos da CPU; profile antes de micro-otimizar a escolha do framework.
Qual escolher?
Novos serviços por padrão para Axum; mantenha Actix quando o custo de migração exceder o benefício.
Relacionados
- Noções Básicas de Backends Web - Introdução com foco em Axum
- Roteamento e Manipuladores do Axum - Equivalente mais próximo no Axum
- Middleware e Tower - Modelo de middleware do Axum
- Testando Serviços Web - Padrões de teste
- Melhores Práticas para Backends Web - Regras agnósticas ao framework
Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.