JustAPI: När Python och Rust slår följe

En fråga som höll en utvecklare vaken

Låt mig börja med en fråga: Varför lägger ditt Python-ramverk så mycket tid på saker som inte har med din kod att göra?

FastAPI bygger på Starlette, som bygger på uvicorn, som omsluter en asyncio-eventloop som hanterar allt mellan socketen och din handler. Varje request – innan den ens når din affärslogik – passerar flera Python-gränser, utlöser serialisering i Python, och dirigeras genom Python-kod som kör på samma sätt för varenda enskild request.

Tänk om det förändrades? Tänk om ramverket – den del som gör identiskt arbete oavsett din applikation – levde helt i Rust, och Python bara körde koden som faktiskt är unik för det du bygger?

Det är grunden bakom JustAPI, och efter att ha granskat projektet tycker jag det är värt att förstå inte bara vad det gör, utan varför arkitekturvalen spelar roll för ditt nästa projekt.

Prestandan är inte vad du tror

Innan vi dyker in i arkitekturen, låt oss prata siffror – för prestandapåståenden utan kontext är marknadsföring, inte ingenjörskonst.

Projektet nådde 766 000 requests per sekund på en enkel hello-world-test. Routern utför lookups på ungefär 51 nanosekunder med 500 routes. Async-kapaciteten förbättrades 14× efter övergången till multi-threaded Tokio med free-threaded CPython-stöd.

Här är vad de siffrorna faktiskt betyder för dig: om du kör ett API som bearbetar tusentals requests per sekund, ackumuleras förbättringarna. Lägre latens betyder kortare väntetid för användarna. Högre throughput betyder att servrarna hanterar mer last. Men den riktiga historien är inte de råa siffrorna – det är vad du slipper hantera.

Ingen uvicorn. Ingen Gunicorn. Ingen ASGI-middleware-stack att felsöka när något går fel klockan tre på natten. Hela request-pipelinen lever i Rust, och din Python-kod är bara... din kod.

Arkitekturen: Python som undantaget, inte regeln

Request-flödet ser ut så här: Kernel (epoll/io_uring) → Tokio connection manager → TLS via rustls → HTTP-parsing via Hyper → Router (matchit radix trie) → Middlewarekedja (auth, CORS, rate-limiting) → Python-gräns via PyO3 → Din handler → Rust serializer → Response.

Lägg märke till var Python kommer in: först vid den punkt där din applikationslogik börjar. Allt innan det – allt som körs identiskt för varje request – är Rust.

Det här är en viktig distinktion. Utvecklaren bakom JustAPI införde en enkel regel under utvecklingen: om en funktion kan implementeras i Rust, måste den implementeras i Rust. Inte "kan vara snabbare i Rust" – kan implementeras i Rust. Python är reserverat för limmet mellan Rust-värden och dina handlers.

Det är en begränsning som format hela projektet och resulterade i något genuint annorlunda från andra Python-ramverk som har byggt på Rust-delar.

Vad det betyder för utvecklarupplevelsen

Här är varför jag tror att det här tillvägagångssättet blir intressant för startups och växande team.

Du får ett komplett API-ramverk – HTTP/1.1 och HTTP/2, TLS, routing med parametrar, JSON-serialisering, automatisk OpenAPI-dokumentation – med 30 rader kod som faktiskt ser ut som Python:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Men under den bekanta ytan kör du en Rust-server som hanterar TLS, hanterar connections och serialiserar responses utan att någonsin gå in i Python. Utvecklarupplevelsen förblir Pythonisk. Körtidsprestandan är Rust.

För team som bygger MVP:er som kanske behöver skala senare spelar det roll. Du skriver Python idag. Du får Rust-prestanda utan att behöva skriva om något när du behöver hantera mer last.

AI-faktorn: En ingenjörspartner, inte en ersättare

Det här projektet byggdes med agentic AI som en aktiv deltagare – inte som autocomplete, utan som en ingenjörsguide som hjälpte designa arkitekturen, omvandla beslut till kod, hitta buggar och skriva tester.

Det är värt att diskutera ärligt, för det blir allt vanligare och sällan pratat om transparent.

Utvecklaren beskriver kodbasen i tre nivåer: delar han förstår fullständigt, delar han förstår tillräckligt bra för att underhålla, och delar AI skrev som han granskade och testade men inte kunde reproducera från minnet. Han är öppen med att det är en del av hur projektet existerar.

Jag tycker det är rätt sätt att se på det. AI-verktyg påskyndar utveckling på komplexa projekt, och att låtsas annorlunda hjälper ingen. Nyckeln är att förstå vad du äger kontra vad du har delegerat – och vara ärlig om vilket som är vilket.

Den praktiska slutsatsen

Ramverk som JustAPI representerar en förskjutning i hur vi tänker om Pythons roll i högpresterande system. Python försvinner inte för applikationslogik – läsbarheten och ekosystemet är för värdefulla. Men antagandet att ramverket själv måste köra i Python utmanas.

Om JustAPI blir ditt nästa ramverk eller förblir ett intressant experiment, har den underliggande insikten värde: titta på vad som kör samma på varje request i din stack. Det är förmodligen Rust-territorium. Delarna som förändras? Behåll de i det språk ditt team är mest produktivt i.

Klyftan mellan "fungerar" och "fungerar bra" krymper hela tiden. Dina användare kommer inte märka arkitekturen, men de kommer märka latensen.

Framåtblick

JustAPI är i version 2.0.10 med dokumenterade features inklusive WebSockets, SSE, background tasks, en scheduler, databasåtkomst via SQLx, och operativt verktyg som OpenTelemetry och Prometheus metrics. Det finns på PyPI med wheels för standard Linux, macOS, Windows, och free-threaded CPython 3.14t build.

Siffrorna finns i repot. Testerna passerar. Misslyckandena är dokumenterade. Det är den typ av ingenjörstransparens vi borde uppmuntra mer av.

Om du bygger Python-API:er och prestanda spelar roll för dig, är det värt en titt. Framtiden för Python-webbramverk kommer kanske inte att se ut som det du använder idag.