JustAPI: Когато Python срещне Rust под капота

Един въпрос ме тормозеше цяла вечер: защо вашият Python уеб framework прекарва толкова много време в неща, които нямат нищо общо с вашия код?

Нека ви дам един пример. Всеки път когато някой извика вашият API endpoint, заявката минава през няколко Python слоя преди да стигне до същината на нещата. Сериализация, routing, ASGI стек — всичко това работи еднакво за всяка една заявка, независимо какво точно прави вашето приложение.

Ами ако това се променеше? Ами ако цялата тази "обща" част — онази, която работи еднакво за всяко приложение — живееше изцяло в Rust, а Python се включваше само когато се изпълнява кодът, който е уникален за това, което вие сте написали?

Това е идеята зад JustAPI. След като прекарах известно време с проекта, смятам че си струва да разберете не само какво прави, но и защо архитектурните му решения имат значение.

Цифрите не са това, което изглеждат

Преди да задълбаем в архитектурата — нека поговорим за производителност. Защото обещания без контекст са маркетинг, не инженерство.

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

Какво означават тези числа за вас на практика? Ако управлявате API, което обработва хиляди заявки в секунда, подобрението се натрупва. По-ниска латентност означава по-малко чакане за потребителите. По-висока пропускателна способност означава повече натоварване на сървърите.

Но истинската история не е в самите числа. Тя е в нещата, които не трябва да управлявате.

Без uvicorn. Без Gunicorn. Без ASGI middleware стек, който да дебъгвате в 3 през нощта. Целият pipeline на заявките е в Rust, а вашият Python код е просто... вашият код.

Архитектурата: Python като изключение, не като правило

Пътят на една заявка изглежда така: ядрото (epoll/io_uring) → Tokio мениджър на връзки → TLS през rustls → HTTP парсиране с Hyper → Router (matchit radix trie) → верига за middleware (auth, CORS, rate-limiting) → Python граница през PyO3 → вашият хендлър → Rust сериализатор → отговор.

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

Това е важна разлика. Разработчикът на JustAPI си е поставил едно просто правило по време на работа: ако дадена функционалност може да бъде имплементирана в Rust, тя трябва да бъде имплементирана в Rust. Не "може да е по-бързо в Rust" — може да бъде имплементирана в Rust. Python е запазен за лепенето между Rust стойностите и вашите хендлъри.

Това е ограничение, което оформи целия проект и доведе до нещо наистина различно от други Python frameworks, които просто са си закачили Rust парчета отгоре.

Какво означава това за developer experience-а

Ето къде смятам, че този подход става интересен за стартъпи и растящи екипи.

Получавате пълен API framework — HTTP/1.1 и HTTP/2, TLS, routing с параметри, JSON сериализация, автоматична OpenAPI документация — с 30 реда код, които изглеждат като нормален Python:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Но под тази позната повърхност работи Rust сървър, който управлява TLS, връзките и сериализира отговорите без никога да преминава в Python. Developer experience-ът остава Python-ски. Производителността на runtime-а е Rust.

За екипи, които правят MVP-та, които може би ще трябва да скалират по-късно, това има значение. Пишете Python днес. Получавате Rust производителност, без да пренаписвате каквото и да било, когато се наложи да поемете по-голямо натоварване.

AI факторът: инженерен партньор, не заместител

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

Струва си да говорим откровено за това, защото става все по-често срещано и рядко се обсъжда прозрачно.

Разработчикът описва codebase-а в три нива: части, които разбира напълно; части, които разбира достатъчно добре, за да ги поддържа; и части, писани от AI, които е прегледал и тествал, но не може да възпроизведе от паметта. Той директно казва, че това е част от начина, по който проектът съществува.

Смятам, че това е правилната рамка. AI инструментите ускоряват разработката на сложни проекти и да се преструваме, че не е така, не помага на никого. Ключовото е да разберете какво притежавате вие срещу това, което сте делегирали — и да сте честни кое от двете е кое.

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

Frameworks като JustAPI представляват промяна в мисленето за ролята на Python в системите с висока производителност. Python няма да отиде никъде за application логика — четимостта и екосистемата му са твърде ценни. Но допускането, че самият framework трябва да работи в Python, се оспорва.

Дали JustAPI ще стане вашият следващ framework или ще си остане интересен експеримент — подлежащата идея има стойност: погледнете какво се изпълнява еднакво на всяка заявка във вашия стек. Там е вероятно мястото за Rust. Частите, които се променят? Запазете ги на който език екипът ви е най-продуктивен.

Разликата между "работи" и "работи добре" става все по-малка. Потребителите ви няма да забележат архитектурата, но ще забележат латентността.

Какво следва

JustAPI е на версия 2.0.10 с документирани функции включително WebSockets, SSE, фонови задачи, scheduler, достъп до бази данни през SQLx, и операционни инструменти като OpenTelemetry и Prometheus метрики. Наличен е в PyPI с wheels за стандартен Linux, macOS, Windows и free-threaded CPython 3.14t build.

Числата са в repository-то. Тестовете минават. Проблемите са документирани. Това е видът инженерна прозрачност, който трябва да насърчаваме повече.

Ако правите Python APIs и производителността ви е важна — струва си да хвърлите един поглед. Бъдещето на Python уеб frameworks може и да не прилича на това, което използвате днес.