Hvorfor din Python-framework bruger tid på alt andet end din kode

Lad mig starte med et spørgsmål, der holdt én udvikler vågen om natten: Hvorfor bruger din Python-webframework så meget tid på ting, der slet ikke har noget med din kode at gøre?

Forestil dig en stack hvor FastAPI hviler på Starlette, som hviler på uvicorn, som igen wrapper en asyncio event loop der håndterer alt mellem socketen og din handler. Hver eneste request — før den overhovedet rammer din forretningslogik — krydser multiple Python-grænser, udløser serialisering i Python, og bliver routet gennem Python-kode der kører på præcis samme måde for hver eneste request.

Hvad nu hvis det ændrede sig? Hvad nu hvis selve framework-delen — den del der udfører identisk arbejde uanset din applikation — levede helt i Rust, og Python kun kørte den kode der faktisk er unik for det du bygger?

Det er præmissen bag JustAPI. Og efter at have brugt tid med projektet, synes jeg det er værd at forstå ikke bare hvad det gør, men hvorfor arkitekturvalgene betyder noget for dit næste projekt.

Performance-tallene er ikke hvad du tror

Før vi dykker ned i arkitekturen, lad os tale tal — for performance-påstande uden kontekst er marketing, ikke engineering.

Projektet nåede 766.000 requests per sekund på en simpel hello-world test. Routeren udfører lookups på cirka 51 nanosekunder med en 500-rute konfiguration. Async throughput steg 14× efter overgangen til multi-threaded Tokio med free-threaded CPython support.

Her er hvad de tal faktisk betyder for dig: kører du en API der processerer tusindvis af requests per sekund, så складываются disse forbedringer. Lavere latency betyder dine brugere venter mindre. Højere throughput betyder dine servere håndterer mere load. Men den egentlige historie er ikke rå-tallene — det er hvad du ikke skal administrere.

Ingen uvicorn. Ingen Gunicorn. Ingen ASGI middleware stack at debugge når noget går galt kl. 3 om natten. Hele request-pipelinen lever i Rust, og din Python-kode er bare... din kode.

Arkitekturen: Python som undtagelsen, ikke reglen

Request-stien ser sådan ud: Kernel (epoll/io_uring) → Tokio connection manager → TLS via rustls → HTTP parsing via Hyper → Router (matchit radix trie) → Middleware kæde (auth, CORS, rate-limiting) → Python grænse via PyO3 → Din handler → Rust serializer → Response.

Læg mærke til hvor Python kommer ind: kun på det punkt hvor din applikationslogik begynder. Alt før det — alt der kører identisk for hver request — er Rust.

Det er en vigtig distinktion. Udvikleren bag JustAPI pålagde sig selv en simpel regel under udviklingen: hvis en funktion kan implementeres i Rust, skal den implementeres i Rust. Ikke "kan være hurtigere i Rust" — kan implementeres i Rust. Python er reserveret til limen mellem Rust-værdier og dine handlers.

Det er en constraint der formede hele projektet og resulterede i noget genuint anderledes fra andre Python-frameworks der har boltet Rust-dele på.

Hvad det betyder for developer experience

Her er hvor jeg synes denne tilgang bliver interessant for startups og voksende teams.

Du får et komplet API-framework — HTTP/1.1 og HTTP/2, TLS, routing med parametre, JSON serialisering, automatisk OpenAPI dokumentation — med 30 linjer kode der faktisk ligner Python:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Men under det bekendte ydre kører du en Rust-server der håndterer TLS, administrerer connections og serialiserer responses uden nogensinde at krydse ind i Python. Developer experience forbliver Pythonic. Runtime performance er Rust.

For teams der bygger MVPs der måske skal skalere senere, betyder det noget. Du skriver Python i dag. Du får Rust performance uden at omskrive noget når du har brug for at håndtere mere load.

AI-faktoren: En ingeniørpartner, ikke en erstatning

Dette projekt blev bygget med agentic AI som aktiv deltager — ikke som autocomplete, men som ingeniørguide der hjalp med at designe arkitekturen, omsætte beslutninger til kode, finde bugs og skrive tests.

Det er værd at diskutere ærligt, fordi det i stigende grad er almindeligt og sjældent snakkes åbent om.

Udvikleren beskriver kodebasen i tre niveauer: dele han forstår fuldstændigt, dele han forstår godt nok til at vedligeholde, og dele AI skrev som han gennemgik og testede men ikke kunne genskabe fra hukommelsen. Han er åben om at det er en del af hvordan projektet eksisterer.

Jeg synes det er den rigtige indstilling. AI-værktøjer accelererer udvikling på komplekse projekter, og at lade som om andet ikke hjælper nogen. Nøglen er at forstå hvad du ejer versus hvad du har delegeret — og være ærlig om hvilket der er hvilket.

Den praktiske takeaway

Frameworks som JustAPI repræsenterer et skift i hvordan vi tænker om Pythons rolle i high-performance systemer. Python er ikke på vej væk fra applikationslogik — dets læsbarhed og økosystem er for værdifuldt. Men antagelsen om at selve frameworket skal køre i Python bliver udfordret.

Uanset om JustAPI bliver dit næste framework eller forbliver et interessant eksperiment, har den underliggende indsigt værdi: kig på hvad der kører ens på hver request i din stack. Det er sandsynligvis Rust-territorium. De dele der ændrer sig? Behold dem på det sprog dit team er mest produktivt i.

Kløften mellem "virker" og "virker godt" bliver ved med at snævre ind. Dine brugere vil ikke bemærke arkitekturen, men de vil bemærke latencyn.

Fremadrettet

JustAPI er på version 2.0.10 med dokumenterede features inklusive WebSockets, SSE, background tasks, en scheduler, database adgang via SQLx, og operationelle værktøjer som OpenTelemetry og Prometheus metrics. Det er tilgængeligt på PyPI med wheels til standard Linux, macOS, Windows, og free-threaded CPython 3.14t build.

Tallene er i repository. Testene passerer. Fejlene er dokumenteret. Det er den slags engineering-gennemsigtighed vi bør opmuntre mere til.

Bygger du Python APIs og performance betyder noget for dig, er det værd at kigge nærmere på. Fremtiden for Python web frameworks ser måske ikke ud som det du bruger i dag.