JustAPI: Když Python běží tam, kde má, a Rust dělá zbytek

Mám pro vás otázku, která jednoho vývojáře nedala spát: Proč váš Python framework tráví tolik času věcmi, které nemají nic společného s vaším kódem?

FastAPI stojí na Starlette, ta na uvicorn, ten zase wrapuje asyncio event loop, který přehazuje všechno mezi socketem a vaším handlerem. Každý request—ještě než se vůbec dostane k vaší business logice—překonává hranice Pythonu, spouští serializaci v Pythonu a prochází kódem, který běží úplně stejně pro úplně každý request.

Co kdyby se to změnilo? Co kdyby framework—ta část, která dělá identickou práci bez ohledu na vaši aplikaci—běžela celá v Rustu, a Python se staral jen o kód, který je opravdu specifický pro to, co stavíte?

Tady začíná příběh JustAPI.

Výkon není o tom, co si myslíte

Než se pustíme do architektury, pojďme na čísla. Protože výkonová tvrzení bez kontextu jsou marketing, ne inženýrství.

Projekt dosáhl 766 000 requestů za sekundu na jednoduchém hello-world testu. Router dělá lookupy přibližně 51 nanosekund na konfiguraci s 500 routama. Async throughput se zlepšil 14× po přechodu na multi-threaded Tokio s free-threaded CPythonem.

Tady je to, co tyhle čísla znamenají v praxi. Když provozujete API, které zpracovává tisíce requestů za sekundu, tyhle zlepšení se skládají. Nižší latence znamená, že uživatelé čekají míň. Vyšší throughput znamená, že servery zvládnou větší zátěž. Ale ten skutečnej příběh nejsou čísla—je to to, co nemusíte spravovat.

Žádnej uvicorn. Žádnej Gunicorn. Žádná ASGI middleware stack, kterou byste ladili ve tři ráno. Celá request pipeline žije v Rustu, a váš Python kód je prostě... váš kód.

Architektura: Python jako výjimka, ne pravidlo

Cesta requestu vypadá takhle: Kernel (epoll/io_uring) → Tokio connection manager → TLS přes rustls → HTTP parsing přes Hyper → Router (matchit radix trie) → Middleware chain (auth, CORS, rate-limiting) → Python boundary přes PyO3 → Váš handler → Rust serializer → Response.

Všimněte si, kde Python vstupuje: jenom v momentě, kdy začíná vaše aplikační logika. Všechno před tím—všechno, co běží identicky pro každej request—je Rust.

To je důležitej rozdíl. Developer za JustAPI si během vývoje stanovil jednoduchý pravidlo: pokud se dá feature implementovat v Rustu, musí se implementovat v Rustu. Ne "může bejt rychlejší v Rustu"—může se implementovat v Rustu. Python je rezervovanej pro lepidlo mezi Rust hodnotama a vašima handlerama.

Je to constrain, kterej formoval celej projekt a vedl k něčemu genuinsky jinýmu než ostatní Python frameworky, co maj Rust díly přidělanej navrch.

Co to znamená pro developer experience

Tady je místo, kde si myslím, že tenhle přístup začíná bejt zajímavej pro startupy a rostoucí týmy.

Dostanete kompletní API framework—HTTP/1.1 a HTTP/2, TLS, routing s parametrama, JSON serializaci, automatický OpenAPI dokumentaci—s 30 řádkama kódu, který opravdu vypadaj jako Python:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Ale pod tou známou fasádou běží Rust server, kterej zvládá TLS, spravuje connectiony a serializuje response, aniž by kdy přecházel do Pythonu. Developer experience zůstává Pythonic. Runtime performance je Rust.

Pro týmy stavějící MVPs, který pak možná budou muset škálovat, tohle dává smysl. Napíšete Python dneska. Dostanete Rust performance bez přepisování čehokoli, až budete potřebovat zvládnout větší zátěž.

AI faktor: Inženýrský parťák, ne náhrada

Tenhle projekt vznikl s agentic AI jako aktivním účastníkem—ne jako autocomplete, ale jako inženýrskej průvodce, kterej pomáhal navrhovat architekturu, přetvářet rozhodnutí v kód, hledat bugy a psát testy.

Tohle stojí za upřímnou diskuzi, protože je to čím dál běžnější a málo se o tom mluví transparentně.

Developer popisuje codebase ve třech úrovních: části, který úplně rozumí; části, který rozumí dost na to, aby je udržel; a části, který napsala AI, který prošel a otestoval, ale než by je zreprodukoval z paměti. Otevřeně říká, že tohle je způsob, jakým projekt existuje.

Myslím, že tohle je správný framing. AI nástroje zrychlují vývoj na komplexních projektech, a předstírat jinak nepomáhá nikomu. Klíčový je rozumět tomu, co vlastníte, versus co jste delegovali—a bejt upřímnej u toho, co je co.

Praktickej postreh

Frameworky jako JustAPI reprezentujou posun v tom, jak přemýšlíme o roli Pythonu v high-performance systémech. Python se nikam nechystá pro aplikační logiku—jeho čitelnost a ekosystém jsou příliš cenný. Ale předpoklad, že framework sám musí běžet v Pythonu, se začíná zpochybňovat.

Ať už se JustAPI stane vaším dalším frameworkem, nebo zůstane zajímavejm experimentem, podkladovej insight má hodnotu: podívejte se na to, co běží stejně na každym requestu ve vašem stacku. Tam je pravděpodobně místo pro Rust. Ty části, co se mění? Ty nechte v jazyce, ve kterým je váš tým nejproduktivnější.

Mezera mezi "funguje" a "funguje dobře" se pořád zmenšuje. Uživatelé si nevšimnou architektury, ale všimnou si latence.

Co dál

JustAPI je ve verzi 2.0.10 s dokumentovanýma featurama včetně WebSockets, SSE, background tasks, scheduleru, přístupu k databázím přes SQLx, a provozních nástrojů jako OpenTelemetry a Prometheus metriky. Je dostupnej na PyPI s wheelama pro standardní Linux, macOS, Windows a free-threaded CPython 3.14t build.

Čísla jsou v repozitáři. Testy procházej. Failure cases jsou zdokumentovaný. Tohle je ten druh inženýrský transparentnosti, kterej bychom měli podporovat víc.

Pokud stavíte Python API a výkon vám není jedno, stojí za to se podívat. Budoucnost Python web frameworků možná nevypadá jako to, co používáte dneska.