JustAPI: Amikor a Python csak azt csinálja, amit te írsz

Van egy kérdés, ami egy fejlesztőt éjszakákon át foglalkoztatott: miért tölt a Python web framework annyi időt olyan dolgokkal, amelyeknek semmi közük a saját kódodhoz?

Nézzük meg, mi történik egy tipikus FastAPI kéréssel. Először jön a Starlette, azon ül az uvicorn, ami az asyncio event loop köré van csomagolva, és az egész kommunikál a socket és a handler között. Minden kérés – még mielőtt elérné a tényleges üzleti logikát – rengeteg Python határon fut át, serialize-olódik Pythonban, és olyan kódon megy keresztül, ami minden egyes kérésnél ugyanúgy fut.

És mi van, ha ez megváltozna? Mi van, ha a framework – az a rész, ami teljesen egyformán fut minden alkalmazásnál – teljes egészében Rustban élne, és a Python csak azokon a helyeken futna, ahol tényleg egyedi dolgot építesz?

Ez a JustAPI alapötlete, és miután alaposan megnéztem a projektet, úgy gondolom, érdemes megérteni nemcsak azt, hogy mit csinál, hanem azt is, miért számítanak az architektúrás döntések a következő projektednél.

A teljesítményszámok nem azt jelentik, amit gondolnál

Mielőtt belemennénk az architektúrába, beszéljünk a számokról – mert teljesítménybeli állítások kontextus nélkül marketing, nem mérnöki munka.

A projekt 766 000 kérést tudott kiszolgálni másodpercenként egy egyszerű hello-world teszten. A router 51 nanoszekundum alatt végez route-lookupot 500 útvonalas konfigurációnál. Az async throughput 14-szeresére javult a multi-threaded Tokio és a free-threaded CPython támogatás bevezetésével.

Mit jelentenek ezek a számok a valóságban? Ha egy API-t üzemeltetsz, ami másodpercenként több ezer kérést dolgoz fel, ezek a javulások összeadódnak. Alacsonyabb latency, kevesebb várakozás a felhasználóknak. Magasabb throughput, több terhelést bír a szerver.

De a lényeg nem is a nyers számokban van – hanem abban, amit nem kell menedzselned.

Nincs uvicorn. Nincs Gunicorn. Nincs ASGI middleware stack, amit hajnali háromkor kell debugolnod. A teljes kérés-pipeline Rustban fut, és a Python kódod csak... a te kódod.

Az architektúra: a Python a kivétel, nem a szabály

Nézzük, hogyan néz ki a kérés útja: Kernel (epoll/io_uring) → Tokio connection manager → TLS a rustls-en → HTTP parsing a Hyper-rel → Router (matchit radix trie) → Middleware lánc (auth, CORS, rate-limiting) → Python határ PyO3-on át → A te handlered → Rust serializer → Response.

Figyeld meg, hol lép be a Python: csak ott, ahol az alkalmazáslogika kezdődik. Ami előtte van – ami minden kérésnél teljesen egyformán fut – az Rust.

Ez fontos különbség. A JustAPI mögött álló fejlesztő egy egyszerű szabályt követett: ha egy feature megvalósítható Rustban, akkor Rustban kell megvalósítani. Nem "gyorsabb lehet Rustban" – megvalósítható Rustban. A Python a ragasztó szerepére van fenntartva a Rust értékek és a handlerek között.

Ez a megkötés formálta a teljes projektet, és valami tényleg más lett belőle, mint a többi Python framework, ami csak odapakolt Rust darabokat.

Mit jelent ez a fejlesztői élmény szempontjából?

Itt válik igazán érdekessé ez a megközelítés a startupok és növekvő csapatok számára.

Kapás egy teljes API frameworket – HTTP/1.1 és HTTP/2, TLS, routing paraméterekkel, JSON serialization, automatikus OpenAPI dokumentáció – 30 sornyi kóddal, ami tényleg úgy néz ki, ahogy Pythonban lennie kell:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

De a ismerős felszín alatt egy Rust szerver fut, ami kezeli a TLS-t, menedzseli a kapcsolatokat és serialize-olja a response-okat – anélkül, hogy egyszer is belépne a Pythonba. A fejlesztői élmény Pythonic marad. A runtime teljesítmény Rust.

Olyan csapatoknak, amik MVP-t építenek, ami később skálázódhat, ez fontos. Ma Pythont írsz. Rust teljesítményt kapsz anélkül, hogy bármit újra kellene írnod, amikor több terhelést kell kezelned.

Az AI faktor: mérnöki partner, nem csere

Ez a projekt agentic AI-t aktív résztvevőként épült – nem autocomplete-ként, hanem mérnöki útmutatóként, aki segített az architektúrát tervezni, döntéseket kóddá alakítani, bugokat találni és teszteket írni.

Érdemes őszintén beszélni erről, mert egyre gyakoribb és ritkán kommunikálják transzparensen.

A fejlesztő a kódbázist három szintre osztja: részek, amiket teljesen megért, részek, amiket elég jól ért a karbantartáshoz, és részek, amiket az AI írt, ő ellenőrzött és tesztelt, de fejből nem tudná reprodukálni. Nyíltan vállalja, hogy ez része annak, ahogy a projekt létezik.

Szerintem ez a helyes keretezés. Az AI eszközök gyorsítják a komplex projektek fejlesztését, és ennek tagadása senkinek nem segít. A lényeg az, hogy tisztában legyél azzal, mi az, amit tényleg értesz, és mi az, amit delegáltál – és őszinte legyél magaddal, melyik melyik.

A gyakorlati tanulság

Az olyan frameworkek, mint a JustAPI, eltolást jelentenek abban, ahogy a Python szerepéről gondolkodunk a nagy teljesítményű rendszerekben. A Python nem megy sehova az alkalmazáslogikához – az olvashatósága és az ökoszisztémája túl értékes. De az a feltételezés, hogy maga a framework is Pythonban kell futjon, megkérdőjeleződik.

Akár a JustAPI lesz a következő frameworked, akár csak egy érdekes kísérlet marad, az alaptétel értékes: nézd meg, mi fut ugyanúgy minden kérésnél a stackedben. Az valószínűleg Rust terület. Ami változik – az maradjon abban a nyelvben, amiben a csapatod a legproduktívabb.

A rés a "működik" és a "jól működik" között egyre szűkül. A felhasználók nem fogják látni az architektúrát, de fogják érezni a latency-t.

Merre tartunk?

A JustAPI jelenleg a 2.0.10-es verziónál tart, dokumentált feature-ökkel mint WebSockets, SSE, background tasks, scheduler, adatbázis hozzáférés SQLx-en át, és operatív eszközök mint OpenTelemetry és Prometheus metrics. Elérhető a PyPI-n, wheel-ekkel Linuxra, macOS-re, Windowsra és a free-threaded CPython 3.14t buildre.

A számok a repóban vannak. A tesztek átmennek. A hibák dokumentáltak. Ez az a mérnöki transzparencia, amit több helyen kellene látnunk.

Ha Python API-kat építesz és a teljesítmény számít, érdemes vetni egy pillantást. A Python web frameworkek jövője lehet, hogy nem úgy néz ki, mint amit ma használsz.