JustAPI: kiedy Rust przejmuje ciężką pracę, a Python może odpocząć

Zaczynam od pytania, które nie dawało mi spać: dlaczego Twój framework Pythona spędza tyle czasu na rzeczach, które nie mają nic wspólnego z Twoim kodem?

FastAPI opiera się na Starlette, które opiera się na uvicorn, które opakowuje pętlę zdarzeń asyncio zarządzającą wszystkim między gniazdem a Twoim handlerem. Każde żądanie — zanim w ogóle dotrze do logiki biznesowej — pokonuje wiele granic Pythona, uruchamia serializację w Pythonie i przechodzi przez kod, który działa tak samo dla każdego żądania.

Co jeśli mogłoby to wyglądać inaczej? Co jeśli framework — ta część, która robi identyczną pracę niezależnie od Twojej aplikacji — żyłaby w całości w Rust, a Python uruchamiał tylko kod, który jest faktycznie unikalny dla tego, co budujesz?

To założenie stoi za JustAPI i po czasie spędzonym z projektem myślę, że warto zrozumieć nie tylko co robi, ale dlaczego decyzje architektoniczne mają znaczenie dla Twojego następnego projektu.

Wyniki wydajnościowe to nie to, co myślisz

Zanim przejdziemy do architektury, porozmawiajmy o liczbach — bo deklaracje wydajnościowe bez kontekstu to marketing, nie inżynieria.

Projekt osiągnął 766 000 żądań na sekundę na podstawowym hello-world. Router wykonuje wyszukiwania w około 51 nanosekundach przy konfiguracji 500 tras. Przepustowość async wzrosła 14-krotnie po przejściu na wielowątkowy Tokio z obsługą free-threaded CPython.

Oto co te liczby oznaczają w praktyce: jeśli prowadzisz API przetwarzające tysiące żądań na sekundę, te usprawnienia się kumulują. Niższa latencja oznacza, że użytkownicy czekają krócej. Wyższa przepustowość oznacza, że serwery obsługują większe obciążenie. Ale prawdziwa historia to nie surowe liczby — to to, czego nie musisz zarządzać.

Nie ma uvicorn. Nie ma Gunicorn. Nie ma stosu middleware ASGI do debugowania, gdy coś pójdzie nie tak o 3 w nocy. Cała ścieżka żądań żyje w Rust, a Twój kod w Pythonie to po prostu... Twój kod.

Architektura: Python jako wyjątek, nie reguła

Ścieżka żądania wygląda tak: Kernel (epoll/io_uring) → menedżer połączeń Tokio → TLS przez rustls → parsowanie HTTP przez Hyper → Router (radix trie matchit) → łańcuch middleware (auth, CORS, rate-limiting) → granica Pythona przez PyO3 → Twój handler → serializer Rust → Odpowiedź.

Zauważ gdzie wchodzi Python: tylko w punkcie, gdzie zaczyna się logika Twojej aplikacji. Wszystko przed tym — wszystko, co uruchamia się identycznie dla każdego żądania — to Rust.

To ważne rozróżnienie. Deweloper stojący za JustAPI narzucił prostą zasadę podczas rozwoju: jeśli funkcję można zaimplementować w Rust, musi być zaimplementowana w Rust. Nie „może być szybsze w Rust" — może być zaimplementowane w Rust. Python jest zarezerwowany na klej między wartościami Rust a Twoimi handlerami.

To ograniczenie ukształtowało cały projekt i zaowocowało czymś naprawdę innym od innych frameworków Pythona, które dokleiły kawałki Rust.

Co to oznacza dla developer experience

Tutaj myślę, że to podejście staje się interesujące dla startupów i rosnących zespołów.

Dostajesz kompletny framework API — HTTP/1.1 i HTTP/2, TLS, routing z parametrami, serializację JSON, automatyczną dokumentację OpenAPI — przy 30 liniach kodu, które wyglądają naprawdę jak Python:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Ale pod tą znajomą powierzchnią działa serwer Rust, który obsługuje TLS, zarządza połączeniami i serializuje odpowiedzi bez przekraczania granicy Pythona. Developer experience pozostaje Pythonic. Wydajność runtime to Rust.

Dla zespołów budujących MVP, które później mogą potrzebować skalowania, to ma znaczenie. Piszesz w Pythonie dziś. Dostajesz wydajność Rust bez przepisywania czegokolwiek, gdy będziesz musiał obsłużyć większe obciążenie.

Czynnik AI: partner inżynierski, nie zamiennik

Ten projekt był budowany z agentic AI jako aktywnym uczestnikiem — nie jako autocomplete, ale jako przewodnik inżynierski, który pomógł zaprojektować architekturę, zamienić decyzje w kod, znaleźć błędy i napisać testy.

To warto uczciwie przedyskutować, bo to jest coraz częstsze i rzadko transparentnie omawiane.

Deweloper opisuje codebase w trzech warstwach: części, które rozumie całkowicie, części, które rozumie wystarczająco dobrze, żeby je utrzymywać, i części napisane przez AI, które przejrzał i przetestował, ale nie potrafiłby odtworzyć z pamięci. Jest otwarty, że to część tego, jak projekt w ogóle istnieje.

Myślę, że to właściwe podejście. Narzędzia AI przyspieszają rozwój złożonych projektów i udawanie, że jest inaczej, nikomu nie pomaga. Klucz to rozumienie, co posiadasz versus co delegowałeś — i szczerość co do tego, co jest czym.

Praktyczny wniosek

Frameworki takie jak JustAPI reprezentują zmianę w myśleniu o roli Pythona w systemach wysokiej wydajności. Python nie idzie nigdzie jeśli chodzi o logikę aplikacji — jego czytelność i ekosystem są zbyt cenne. Ale założenie, że sam framework musi działać w Pythonie, jest kwestionowane.

Czy JustAPI stanie się Twoim następnym frameworkiem, czy pozostanie interesującym eksperymentem, fundamentalna intuicja ma wartość: przyjrzyj się temu, co uruchamia się tak samo przy każdym żądaniu w Twoim stacku. To prawdopodobnie terytorium Rust. Części, które się zmieniają? Zostaw te w języku, w którym Twój zespół jest najbardziej produktywny.

Przerwa między „działa" a „działa dobrze" stale się zmniejsza. Użytkownicy nie zauważą architektury, ale zauważą latencję.

Spojrzenie w przyszłość

JustAPI jest w wersji 2.0.10 z udokumentowanymi funkcjami obejmującymi WebSockety, SSE, background tasks, scheduler, dostęp do bazy danych przez SQLx, oraz narzędzia operacyjne jak OpenTelemetry i metryki Prometheus. Dostępny na PyPI z wheelami dla standardowego Linuksa, macOS, Windows i free-threaded CPython 3.14t.

Liczby są w repozytorium. Testy przechodzą. Awarie są udokumentowane. To rodzaj transparentności inżynierskiej, którą powinniśmy bardziej wspierać.

Jeśli budujesz API w Pythonie i wydajność jest dla Ciebie ważna, warto rzucić okiem. Przyszłość pythonowych frameworków webowych może nie wyglądać jak to, czego używasz dzisiaj.