В чём разница между Axum и Actix-web по архитектуре, дизайну API и производительности?

Система маршрутизации и экстракторов

// Axum — экстракторы через типы аргументов
async fn axum_handler(
    Path(id): Path<u32>,
    State(db): State<PgPool>,
    Json(body): Json<CreateUser>,
) -> impl IntoResponse { /* ... */ }

// Actix-web — web::Data, web::Path, web::Json как параметры
async fn actix_handler(
    path: web::Path<u32>,
    db: web::Data<PgPool>,
    body: web::Json<CreateUser>,
) -> impl Responder { /* ... */ }

Axum vs Actix-web: архитектура, API и производительность

Архитектурные основы

Actix-web изначально строился на актор-фреймворке Actix, но с версии 4.x «акторный» слой убран из основного пути обработки запросов. Тем не менее он использует собственный runtime-слой и собственную систему middleware (интерфейс Transform + Service). Actix-web самодостаточен и не зависит от Tower.

Axum — это тонкий слой над hyper (HTTP) и tower (middleware). Он намеренно не предоставляет собственных примитивов middleware — вместо этого используются Tower-сервисы (tower::ServiceBuilder, tower-http). Это даёт совместимость со всей экосистемой Tower.

Middleware

В Axum middleware — это Tower-сервис. Использование tower_http::trace::TraceLayer, tower_http::cors::CorsLayer, tower_http::compression::CompressionLayer — нативное:

use tower_http::{trace::TraceLayer, cors::CorsLayer, compression::CompressionLayer};
use tower::ServiceBuilder;

let app = Router::new()
    .route("/", get(handler))
    .layer(
        ServiceBuilder::new()
            .layer(TraceLayer::new_for_http())
            .layer(CorsLayer::permissive())
            .layer(CompressionLayer::new()),
    );

В Actix-web middleware оборачивается через wrap() и реализует трейты Transform и Service — это более verbose и несовместимо с Tower.

Обработка ошибок

Axum использует IntoResponse — любой тип, реализующий этот трейт, может быть возвращён из обработчика. Actix-web использует Responder + тип ошибки ResponseError.

Производительность

В бенчмарках TechEmpower (JSON serialization, plaintext) оба фреймворка входят в топ-5 среди всех языков. Actix-web исторически чуть быстрее в микробенчмарках за счёт более прямого пути обработки, Axum немного уступает из-за абстракции Tower. На практике разница менее 5–10% и нивелируется ввода-выводом БД или сети.

Когда выбирать что

• Axum: команда уже использует Tower/tonic/hyper; нужна максимальная совместимость с экосистемой Tokio.
• Actix-web: нужен зрелый фреймворк с большей документацией и примерами; важна максимальная сырая производительность.

Подводные камни

• Tower-middleware в Axum требует, чтобы все слои реализовывали Clone — это может быть неочевидно для кастомных сервисов.
• Actix-web имеет собственный thread-pool и не требует явного Tokio runtime, что может запутать при интеграции с Tokio-кодом.
• Типы ошибок у фреймворков несовместимы — миграция с одного на другой требует переписи всего слоя ошибок.
• В Axum нет встроенного multipart/form-data — нужен крейт axum-multipart или multer. В Actix-web multipart встроен.
• Экстракторы Axum вычисляются последовательно — порядок параметров функции имеет значение (Body должен быть последним).
• Actix-web использует web::Data<T> как Arc<T> неявно; в Axum нужно явно оборачивать в Arc при необходимости.

• Отвечать определением без production-сценария.
• Не называть runtime boundary, security boundary или failure mode.
• Игнорировать версию API, observability и тестовую проверку.

• Объясняет механизм своими словами и без выдуманных API.
• Называет реальные риски, диагностику и критерий корректности.
• Связывает ответ с текущей документацией и миграционными ограничениями.