JustAPI: когда Python уступает дорогу Rust

Вопрос, который не давал мне покоя: почему ваш Python-фреймворк тратит столько времени на то, что вообще не касается вашего кода?

FastAPI работает на Starlette, тот — на uvicorn, который оборачивает asyncio event loop. Каждый запрос — ещё до того как дойдёт до вашей бизнес-логики — пересекает несколько Python-границ, вызывает сериализацию в Python, проходит через код, который работает одинаково для всех запросов.

А что если это изменить? Что если фреймворк — та часть, которая делает одно и то же независимо от приложения — живёт целиком в Rust, а Python запускает только то, что действительно уникально для вашего проекта?

Именно это предлагает JustAPI. И после знакомства с проектом я думаю, что стоит разобраться не только в том, что он делает, но и почему архитектурные решения имеют значение.

Цифры — это не всё, но без них никуда

Начнём с бенчмарков, потому что заявления о производительности без данных — это маркетинг, а не инженерия.

Проект достиг 766 000 запросов в секунду на базовом hello-world. Маршрутизация занимает около 51 наносекунды при конфигурации из 500 routes. Асинхронная пропускная способность выросла в 14 раз после перехода на multi-threaded Tokio с поддержкой free-threaded CPython.

Что это значит на практике? Если ваше API обрабатывает тысячи запросов в секунду, улучшения складываются. Меньше latency — пользователи ждут меньше. Больше throughput — серверы справляются с большей нагрузкой.

Но главное — это то, что вам больше не нужно администрировать. Никакого uvicorn. Никакого Gunicorn. Никакого стека ASGI middleware, который приходится отлаживать в три часа ночи. Весь pipeline запроса живёт в Rust, а ваш Python-код — это просто ваш код.

Архитектура: Python как исключение

Путь запроса выглядит так: Kernel (epoll/io_uring) → Tokio connection manager → TLS через rustls → HTTP-парсинг через Hyper → Router (matchit radix trie) → Цепочка middleware (auth, CORS, rate-limiting) → Граница Python через PyO3 → Ваш handler → Rust-сериализатор → Response.

Заметьте: Python подключается только в точке, где начинается ваша бизнес-логика. Всё до этого — всё, что выполняется одинаково для каждого запроса — это Rust.

Здесь важна формулировка. Разработчик JustAPI задал себе простое правило: если функцию можно реализовать в Rust, она должна быть реализована в Rust. Не «можно быстрее в Rust» — именно «можно реализовать в Rust». Python зарезервирован для связки между Rust-значениями и вашими handlers.

Это ограничение сформировало весь проект и результат получился по-настоящему другим, не тем ущербным поделием из Rust-компонентов, которые иногда встречаются в Python-фреймворках.

Опыт разработки

Вот где этот подход становится интересным для стартапов и растущих команд.

Вы получаете полноценный API-фреймворк — HTTP/1.1 и HTTP/2, TLS, маршрутизация с параметрами, JSON-сериализация, автоматическая OpenAPI-документация — написав 30 строк кода, которые выглядят как самый обычный Python:

from justapi import JustAPIApp

app = JustAPIApp()

@app.get("/")
def hello():
    return {"Hello": "World"}

app.run()

Но под знакомым интерфейсом работает Rust-сервер, который обрабаывает TLS, управляет соединениями и сериализует ответы, ни разу не заходя в Python. Опыт разработки остаётся Pythonic. Производительность — от Rust.

Для команд, которые делают MVP и потом могут масштабироваться, это важно. Пишете на Python сегодня. Получаете Rust-производительность без переписывания, когда нагрузка вырастет.

Роль AI: инженерный партнёр, а не замена

Проект создавался с активным участием agentic AI — не как автодополнение кода, а как инженерный советник, который помогал проектировать архитектуру, превращать решения в код, находить баги и писать тесты.

Стоит обсудить это честно, потому что такое встречается всё чаще, а говорят об этом редко.

Разработчик описывает кодовую базу тремя уровнями: части, которые он понимает полностью; части, которые он понимает достаточно, чтобы поддерживать; и части, которые AI написал, а он проверил и протестировал, но не смог бы воспроизвести по памяти. Он открыто говорит, что это часть того, как проект существует.

Я думаю, это правильный подход. AI-инструменты ускоряют разработку сложных проектов, и притворяться иначе никому не помогает. Ключевое — понимать, что вы контролируете, а что делегировали, и быть честным в этом разделении.

Практический вывод

Фреймворки вроде JustAPI отражают сдвиг в мышлении о роли Python в high-performance системах. Python никуда не уходит для бизнес-логики — его читаемость и экосистема слишком ценны. Но идея, что сам фреймворк должен работать в Python, подвергается сомнению.

Будет ли JustAPI вашим следующим фреймворком или останется интересным экспериментом — неважно. Ценна сама идея: посмотрите, что в вашем стеке работает одинаково для каждого запроса. Это, скорее всего, территория Rust. А части, которые меняются? Оставьте их на том языке, на котором ваша команда работает продуктивнее.

Расстояние между «работает» и «хорошо работает» продолжает сокращаться. Пользователи не заметят архитектуру, но заметят latency.

Статус проекта

JustAPI сейчас на версии 2.0.10. Документированные фичи включают WebSockets, SSE, background tasks, планировщик, доступ к базам данных через SQLx, операционные инструменты вроде OpenTelemetry и Prometheus metrics. Пакет доступен на PyPI с wheels для стандартного Linux, macOS, Windows и free-threaded CPython 3.14t.

Цифры есть в репозитории. Тесты проходят. Известные проблемы задокументированы. Это тот уровень инженерной прозрачности, который стоит поддерживать.

Если вы строите Python API и производительность важна — попробуйте. Будущее Python-фреймворков, возможно, выглядит не так, как то, чем вы пользуетесь сейчас.