Backend: Почему не легкие http библиотеки, а тяжелые фреимворки¶
Синтетика vs реальный бэкенд¶
Синтетические бенчмарки != реальный бэкенд
Синтетический тест типа GET /json меряет почти только:
- скорость HTTP-стека
- аллокации/системные вызовы
В таких условиях:
- Rust/C++ + лёгкий HTTP-сервер легко делают десятки–сотни тысяч RPS
- тяжёлый фреймворк (Spring, Django) выглядит слишком медленным
Но реальный бэкенд — это:
- SQL/NoSQL БД
- сложная бизнес-логика
- транзакции, очереди, кэши
- авторизация, логирование, валидация, мониторинг
Там узкое место почти всегда БД и внешние сервисы, а не обёртка HTTP. Разница между 20k и 60k RPS на синтетике перестаёт быть главной.
Что дают тяжёлые фреймворки, чего нет у голых HTTP-библиотек¶
Spring / .NET / Nest и т.д. дают из коробки:
- DI-контейнер, конфиги, профили, автосборку контекста
- валидацию, сериализацию, фильтры, interceptors
- security (OAuth2, JWT, RBAC)
- транзакции и интеграцию с БД
- health-checks, metrics, tracing, интеграцию с k8s
- огромную экосистему библиотек и готовых решений
Лёгкая HTTP-библиотека на Rust/C++ — это обычно:
- дай сокет, дай хендлер, дальше сам
- всё окружение: DI, конфиги, миграции, monitoring, auth надо дописать руками или собирать из разрозненных кусков.
В итоге, Да, RPS выше, но стоимость разработки и сопровождения вырастает, особенно для команды из обычных enterprise-разработчиков.
Где лёгкие HTTP-стеки (Rust/C++) реально уместны¶
Подходят отлично для:
- очень простых, но экстремально нагруженных сервисов (proxy, шлюзы, edge-сервисы, gRPC-прокси)
- узкоспециализированных компонентов: свой брокер, свой кеш, свой специализированный API-шлюз
- когда команда силён в системном C++/Rust и осознанно выбирает такой стек
И намного хуже подходят для:
- типичного бизнес-бэкенда: учёт, CRM, биллинг, логистика, много сущностей + куча правил + отчётики
- проектов, где важнее скорость разработки, читабельность и поддерживаемость, чем выигрыш в 20–30% по latency
Итог¶
Лёгкие HTTP-библиотеки на Rust/C++ показывают шикарные цифры в синтетических бенчмарках, потому что они минимальны по накладным расходам и меряется почти только голый HTTP. Но реальный бэкенд упирается в БД и сложную бизнес-логику, а не в HTTP-обёртку. Для таких задач важнее не максимальный RPS на GET /hello, а экосистема, транзакции, безопасность, мониторинг и скорость разработки. Этого как раз дают крупные фреймворки (Spring и др.), а в случае “голых” Rust/C++-библиотек большую часть инфраструктуры приходится писать самому. Поэтому они отлично подходят для низкоуровневых, специализированных и edge-сервисов, но часто не являются практичным выбором как основной стек для типичного бизнес-бэкенда.