Derfor bør du vurdere JustAPI

Her er et spørsmål som kanskje har holdt en utvikler våken: Hvorfor bruker Python-rammeverket ditt så mye tid på oppgaver som ikke har noe med koden din å gjøre?

FastAPI hviler på Starlette, som igjen hviler på uvicorn, som håndterer en asyncio event loop som balanserer alt mellom socketen og handleren din. Hver eneste forespørsel — før den i det hele tatt når forretningslogikken din — krysser flere Python-grenser, triggier serialisering i Python, og går gjennom Python-kode som kjører på nøyaktig samme måte for absolutt alle forespørsler.

Hva om det endret seg? Hva om selve rammeverket — altså delen som gjør identisk arbeid uansett hvilken applikasjon du bygger — levde fullstendig i Rust, og Python bare kjørte koden som faktisk er unik for det du lager?

Det er premisset bak JustAPI, og etter å ha brukt tid på prosjektet, tror jeg det er verdt å forstå ikke bare hva det gjør, men hvorfor arkitekturvalgene betyr noe for ditt neste prosjekt.

Tallene som forteller mer enn bare hastighet

La oss snakke om måltall før vi dykker ned i arkitekturen — fordi påstander om ytelse uten kontekst er markedsføring, ikke ingeniørarbeid.

Prosjektet nådde 766 000 forespørsler per sekund på en enkel hello-world-test. Ruteren utfører oppslag på rundt 51 nanosekunder med en 500-rute-konfigurasjon. Async-throughput økte 14× etter overgangen til multi-threaded Tokio med free-threaded CPython-støtte.

Her er hva de tallene faktisk betyr for deg: Hvis du kjører en API som behandler tusenvis av forespørsler per sekund, forsterkes disse forbedringene. Lavere latency betyr at brukerne venter mindre. Høyere throughput betyr at serverne dine håndterer mer last. Men den egentlige historien er ikke råtallene — det er alt du slipper å administrere.

Ingen uvicorn. Ingen Gunicorn. Ingen ASGI-middleware-stakk å feilsøke når noe går galt klokken 03. Hele forespørselsrørledningen lever i Rust, og Python-koden din er bare... din kode.

Arkitekturen: Python som unntaket, ikke regelen

Forespørselsbanen ser slik ut: Kernel (epoll/io_uring) → Tokio-tilkoblingshåndtering → TLS via rustls → HTTP-parsing via Hyper → Ruter (matchit radix trie) → Mellomvarekjede (auth, CORS, rate-limiting) → Python-grensesnitt via PyO3 → Din handler → Rust-serializer → Svar.

Legg merke til hvor Python kommer inn: bare på det punktet der forretningslogikken din begynner. Alt før det — alt som kjører identisk for hver eneste forespørsel — er Rust.

Dette er en viktig distinksjon. Utvikleren bak JustAPI innførte en enkel regel under utviklingen: hvis en funksjon kan implementeres i Rust, skal den implementeres i Rust. Ikke «kan være raskere i Rust» — kan implementeres i Rust. Python er reservert for limet mellom Rust-verdier og handlerne dine.

Det er en begrensning som formet hele prosjektet og resulterte i noe som virkelig er annerledes fra andre Python-rammeverk som har boltet på Rust-deler.

Hva dette betyr for utvikleropplevelsen

Her er hvor jeg tror denne tilnærmingen blir interessant for startups og voksende team.

Du får et komplett API-rammeverk — HTTP/1.1 og HTTP/2, TLS, routing med parametere, JSON-serialisering, automatisk OpenAPI-dokumentasjon — med 30 linjer kode som faktisk ser ut som Python:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Men under den kjente overflaten kjører du en Rust-server som håndterer TLS, administrerer tilkoblinger og serialiserer svar uten noen gang å krysse inn i Python. Utvikleropplevelsen er Pythonic. Kjøretidsytelsen er Rust.

For team som bygger MVP-er som kanskje trenger å skalere senere, betyr dette noe. Du skriver Python i dag. Du får Rust-ytelse uten å skrive om noe når du trenger å håndtere mer last.

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

Dette prosjektet ble bygget med agentisk AI som en aktiv deltaker — ikke som autofullfør, men som en ingeniørveileder som hjalp til med å designe arkitekturen, omsette beslutninger til kode, finne feil og skrive tester.

Det er verdt å diskutere ærlig, fordi det blir stadig vanligere og sjelden snakket transparent om.

Utvikleren beskriver kodebasen i tre nivåer: deler han forstår fullstendig, deler han forstår godt nok til å vedlikeholde, og deler AI skrev som han har gjennomgått og testet men ikke kunne reprodusert fra hukommelsen. Han er åpen om at dette er en del av hvordan prosjektet eksisterer.

Jeg synes det er riktig innramming. AI-verktøy akselererer utvikling på komplekse prosjekter, og å late som noe annet hjelper ingen. Nøkkelen er å forstå hva du eier kontra hva du har delegert — og være ærlig om hva som er hva.

Den praktiske lærdommen

Rammeverk som JustAPI representerer et skifte i hvordan vi tenker om Pythons rolle i høytytende systemer. Python forsvinner ikke fra forretningslogikk — lesbarheten og økosystemet er for verdifulle. Men antakelsen om at selve rammeverket må kjøre i Python blir utfordret.

Enten JustAPI blir ditt neste rammeverk eller forblir et interessant eksperiment, har den underliggende innsikten verdi: se på hva som kjører likt på hver forespørsel i stacken din. Det er sannsynligvis Rust-territorium. Delene som endrer seg? Behold de på det språket teamet ditt er mest produktivt i.

Gallet mellom «fungerer» og «fungerer godt» blir stadig smalere. Brukerne dine vil ikke legge merke til arkitekturen, men de vil legge merke til latensen.

Veien videre

JustAPI er ved versjon 2.0.10 med dokumenterte funksjoner som WebSockets, SSE, bakgrunnsoppgaver, en scheduler, database-tilgang via SQLx, og operasjonelle verktøy som OpenTelemetry og Prometheus-metriker. Det er tilgjengelig på PyPI med wheels for standard Linux, macOS, Windows, og free-threaded CPython 3.14t-build.

Tallene er i repositoryen. Testene passerer. Feilene er dokumentert. Det er den typen teknisk transparens vi bør oppmuntre til mer av.

Hvis du bygger Python-API-er og ytelse betyr noe for deg, er det verdt et blikk. Fremtiden til Python web-rammeverk ser kanskje ikke ut som det du bruker i dag.