JustAPI: Rust-pyörällä Python-webin tulevaisuuteen?

Aloitetaan kysymyksellä, joka piti erään kehittäjän hereillä yöllä: miksi Python-webframeworki käyttää niin paljon aikaa asioihin, joilla ei ole mitään tekemistä sinun koodisi kanssa?

FastAPI nojaa Starletteen, joka nojaa uvicorniin, joka käärii asyncio-event loopin. Jokainen request–ennen kuin se edes pääsee liiketoimintalogiikkaasi–ylittää useita Python-rajoja, käynnistää serialisoinnin Pythonissa ja reitittyy Python-koodin läpi, joka pyörii täsmälleen samalla tavalla jokaiselle requestille.

Entä jos tämä muuttuisi? Entä jos framework–osa, joka tekee identtistä työtä sovelluksestasi riippumatta–eläisi kokonaan Rustissa, ja Python pyörittäisi vain koodia, joka on todella ainutlaatuista sinun rakennelmalle?

Tämä on JustAPIn lähtökohta. Ja projektin parissa vietetyn ajan jälkeen uskon, että sen arvoinen on ymmärtää paitsi mitä se tekee, myös miksi arkkitehtuuripäätökset merkitsevät seuraavalle projektillesi.

Suorituskykyluvut eivät ole sitä, mitä luulet

Ennen arkkitehtuuriin sukeltamista puhutaan numeroista. Suorituskykylupaukset ilman kontekstia ovat markkinointia, eivät insinööritaitoa.

Projekti ylsi 766 000 requestiin sekunissa yksinkertaisella hello-world-testillä. Reititin suorittaa hakuja noin 51 nanosekunnissa 500 reitin konfiguraatiolla. Async-suorituskyky parani 14-kertaisesti siirryttäessä monisäikeiseen Tokioon free-threaded CPython-tuen kera.

Mitä nämä luvut käytännössä tarkoittavat? Jos pyörität API:a, joka käsittelee tuhansia requestejä sekunissa, nämä parannukset kasaantuvat. Pienempi latenssi tarkoittaa lyhyempää odotusaikaa käyttäjille. Suurempi läpimeno tarkoittaa, että palvelimet käsittelevät enemmän kuormaa.

Mutta todellinen tarina ei ole raaka numero. Se on se, mitä sinun ei tarvitse hallinnoida.

Ei uvicornia. Ei Gunicornia. Ei ASGI-middleware-pinoa, jota debugata keskellä yötä kun jotain menee pieleen. Koko request-putki elää Rustissa, ja Python-koodisi on vain... koodiasi.

Arkkitehtuuri: Python poikkeuksena, ei sääntönä

Request-reitti näyttää tältä: Kernel (epoll/io_uring) → Tokio-yhteyshallinta → TLS rustls:n kautta → HTTP-jäsennys Hyperillä → Reititin (matchit radix trie) → Middleware-ketju (autentikointi, CORS, rate-limiting) → Python-raja PyO3:n kautta → Oma handleri → Rust-serialisoija → Vastaus.

Huomaa, missä Python astuu kuvaan: vain siinä vaiheessa, kun sovelluslogiikkasi alkaa. Kaikki ennen sitä–kaikki, mikä pyörii identtisesti jokaiselle requestille–on Rustia.

Tämä on tärkeä ero. JustAPIn takana oleva kehittäjä asetti yksinkertaisen säännön projektin aikana: jos ominaisuus voidaan toteuttaa Rustissa, se täytyy toteuttaa Rustissa. Ei "voi olla nopeampi Rustissa"–vaan voidaan toteuttaa Rustissa. Python on varattu liimaksi Rust-arvojen ja omien handlerien väliin.

Tämä rajoite muokkasi koko projektia ja tuotti jotain aidosti erilaista verrattuna muihin Python-frameworkeihin, jotka ovat lisänneet Rust-paloja jälkikäteen.

Mitä tämä tarkoittaa kehittäjäkokemukselle?

Tässä kohtaa lähestymistapa muuttuu mielenkiintoiseksi startupeille ja kasvaville tiimeille.

Saat täydellisen API-frameworkin–HTTP/1.1 ja HTTP/2, TLS, reitityksen parametreilla, JSON-serialisoinnin, automaattisen OpenAPI-dokumentaation–30 rivillä koodia, joka näyttää oikeasti Pythonilta:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Mutta tutun pinnan alla pyörittät Rust-palvelinta, joka hoitaa TLS:n, hallitsee yhteyksiä ja serialisoi vastauksia koskaan ylittämättä Python-rajaa. Kehittäjäkokemus on Pythonic. Suorituskyky on Rustia.

Tiimeille, jotka rakentavat MVP:tä, joka saattaa tarvita skaalausta myöhemmin, tämä merkitsee. Kirjoitat tänään Pythonia. Saat Rust-suorituskyvyn ilman uudelleenkirjoitusta, kun kuorma kasvaa.

AI-tekijä: Insinöörikumppani, ei korvaaja

Tämä projekti rakennettiin agentic AI:n aktiivisena osapuolena–ei.autocomplete-näppäimenä, vaan insinöörioppaana, joka auttoi suunnittelemaan arkkitehtuuria, muuttamaan päätöksiä koodiksi, löytämään bugeja ja kirjoittamaan testejä.

Tämä ansaitsee rehellisen keskustelun, koska se on yhä yleisempää mutta harvoin läpinäkyvästi esillä.

Kehittäjä kuvaa koodikantaa kolmella tasolla: osat, jotka hän ymmärtää täysin; osat, jotka hän ymmärtää riittävästi ylläpitääkseen; ja osat, jotka AI kirjoitti ja jotka hän tarkisti ja testasi, mutta joita ei pystyisi toistamaan muistista. Hän on suora siitä, että tämä on osa projektin olemassaoloa.

Uskon tämän olevan oikea kehystäminen. AI-työkalut nopeuttavat kehitystä monimutkaisissa projekteissa, ja sen kiistäminen ei auta ketään. Avain on ymmärtää, mitä omistat verrattuna siihen, mitä olet ulkoistanut–ja olla rehellinen siitä, kumpi on kumpi.

Käytännön takeaway

Frameworkit kuten JustAPI edustavat ajattelutavan muutosta siitä, mikä on Pythonin rooli korkean suorituskyvyn järjestelmissä. Python ei mihinkään katoa sovelluslogiikassa–sen luettavuus ja ekosysteemi ovat liian arvokkaita. Mutta oletus siitä, että frameworkin itsensä täytyy pyöriä Pythonissa, haastetaan.

Olipa JustAPI seuraava frameworkisi tai vain kiinnostava kokeilu, taustalla oleva oivallus on arvokas: katso, mikä pyörii samalla tavalla jokaisen requestin kohdalla pinossasi. Se on todennäköisesti Rust-aluetta. Osat, jotka muuttuvat? Pidä ne siinä kielessä, jossa tiimisi on tuottavin.

Kuilu "toimii" ja "toimii hyvin" kapenee jatkuvasti. Käyttäjät eivät huomaa arkkitehtuuria, mutta he huomaavat latenssin.

Katse eteenpäin

JustAPI on versiossa 2.0.10. Dokumentoidut ominaisuudet sisältävät WebSockets-tuen, SSE:n, taustatehtävät, ajastimen, tietokantayhteydet SQLx:n kautta sekä operatiiviset työkalut kuten OpenTelemetry-integraation ja Prometheus-metriikat. Se on saatavilla PyPI:ssä valmiina wheel-paketteina Linuxille, macOS:lle, Windowsille ja free-threaded CPython 3.14t -buildille.

Luvut ovat repositorossa. Testit menevät läpi. Epäonnistumiset on dokumentoitu. Tämänlaatuinen insinööriläpinäkyvyys on jotain, mitä meidän pitäisi nähdä enemmän.

Jos rakennat Python-API:a ja suorituskyky merkitsee, se kannattaa tarkistaa. Python-web-frameworkien tulevaisuus ei ehkä näytä siltä, mitä käytät tänään.