В каких backend-проектах Axum (Rust) является сильным выбором, а где лучше выбрать более простой или другой стек?

Когда Axum — правильный выбор

Axum (на базе Tokio + Tower) хорошо проявляет себя в следующих сценариях:

• Высоконагруженные REST/gRPC API — нулевые накладные расходы на GC, latency p99 стабильно ниже, чем у JVM или Python.
• WebSocket-интенсивные сервисы — тысячи одновременных соединений в одном процессе без дополнительной инфраструктуры.
• Edge и serverless — компактные бинари (~5–15 MB), быстрый cold start, подходит для WASM-деплоя.
• Финансовые и safety-critical сервисы — borrow checker исключает data races и use-after-free на уровне компилятора.
• Долгоживущие фоновые воркеры — предсказуемое потребление памяти без утечек.

Пример минимального сервиса с маршрутизацией и общим состоянием:

use axum::{
    extract::State,
    routing::get,
    Json, Router,
};
use std::sync::{Arc, Mutex};

#[derive(Clone)]
struct AppState {
    counter: Arc<Mutex<u64>>,
}

async fn increment(State(state): State<AppState>) -> Json<u64> {
    let mut c = state.counter.lock().unwrap();
    *c += 1;
    Json(*c)
}

#[tokio::main]
async fn main() {
    let state = AppState {
        counter: Arc::new(Mutex::new(0)),
    };
    let app = Router::new()
        .route("/increment", get(increment))
        .with_state(state);
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

Компилируется и запускается без внешних зависимостей, кроме Tokio.

Когда выбирать другой стек

Axum — плохой выбор в следующих ситуациях:

• Прототип или MVP с жёстким дедлайном — время до первого деплоя на FastAPI или Express в 2–5 раз меньше: нет борьбы с borrow checker, богаче экосистема готовых решений.
• Команда без опыта Rust — кривая обучения крутая; lifetime-ошибки компилятора непривычны, async Rust добавляет дополнительный слой сложности.
• CRUD-сервис с ORM и сложными транзакциями — SQLAlchemy (Python) или Hibernate (Java) несравнимо богаче по возможностям, чем sqlx или sea-orm.
• ML-inference внутри HTTP-сервера — Python-сервис нативно подключает PyTorch/TensorFlow; из Rust придётся вызывать C API или отдельный микросервис.
• Скрипты и glue-сервисы — время компиляции и усилия на сборку не окупаются для небольших утилит.

Сравнение по ключевым осям

• Производительность: Axum ≈ Go (Gin/Fiber), оба быстрее Node/Python на CPU-bound задачах; разрыв на IO-bound меньше.
• Найм: Rust-разработчиков меньше и они дороже; Go и Python — более широкий рынок.
• Экосистема: crates.io богатый, но ряд категорий (CMS, full-stack фреймворки) уступает npm/PyPI по зрелости.
• Инфраструктурная стоимость: меньше RAM и CPU → дешевле при масштабировании, но дороже в разработке.
• Безопасность: compile-time гарантии снижают класс уязвимостей, но не заменяют аудит бизнес-логики.

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

• Async Rust сложнее async Python/JS — Send + Sync bounds на futures ломают компиляцию при передаче не-Send типов (например, Rc или MutexGuard) через await.
• Извлечение из запроса потребляет тело — если добавить второй экстрактор Body или Bytes, компилятор откажет; нужно буферизировать вручную через bytes::Bytes.
• Middleware через Tower непривычен — Layer и ServiceBuilder требуют понимания tower::Service, иначе типовые ошибки невозможно читать.
• Время компиляции — большой проект с tokio, axum, sqlx компилируется 1–3 минуты в debug-режиме; CI без кеша болезненно медленный.
• Обработка ошибок требует явного IntoResponse — нельзя вернуть произвольный Box<dyn Error>; нужно реализовать трейт или использовать thiserror/anyhow совместно с кастомным типом.
• Глобальное состояние через Arc<Mutex> — легко создать узкое место; для высококонкурентного состояния лучше DashMap или канальная архитектура с актором.
• Версионирование crates — tower, hyper, axum исторически меняли API между мажорными версиями; зависимости сторонних библиотек могут тянуть несовместимые версии hyper.
• Отсутствие встроенного DI-контейнера — в Java/Spring DI из коробки; в Axum инъекция зависимостей реализуется вручную через State или Extension, что усложняет тестирование крупных сервисов.

• Выбирать Axum (Rust) по популярности, а не по требованиям проекта
• Игнорировать опыт команды, эксплуатацию и стоимость поддержки
• Не называть ситуации, где Axum (Rust) будет плохим выбором

• Называет критерии выбора Axum (Rust)
• Учитывает команду, эксплуатацию, стоимость и риски
• Может назвать сценарии, где выбрал бы альтернативу