Waarom zou jouw Python-framework tijd besteden aan dingen die niet jouw code zijn?

Stel jezelf een vraag die menig developer wakker houdt: waarom besteedt je Python webframework zoveel tijd aan werk dat niets te maken heeft met wat je zelf hebt geschreven?

FastAPI draait op Starlette, dat draait op uvicorn, dat weer een asyncio event loop wrapt die alles regelt tussen de socket en jouw handler. Elke request—voordat je business logic überhaupt wordt aangeraakt—passering meerdere Python-grenzen, triggert serialisatie in Python, en wordt gerouteerd door Python code die exact hetzelfde draait voor elke incoming request.

Wat als dat veranderde? Wat als het framework—dat deel dat identiek werk verricht ongeacht je applicatie—volledig in Rust zou leven, en Python alleen draait waar je code uniek is?

Dat is het uitgangspunt achter JustAPI. Na tijd te hebben doorgebracht met het project, denk ik dat het de moeite waard is om te begrijpen wat het doet én waarom de architectuurkeuzes ertoe doen voor je volgende project.

De performance-verhalen zijn niet wat je denkt

Voordat we in de architectuur duiken, eerst de cijfers—want performanceclaims zonder context zijn marketing, geen techniek.

Het project haalde 766.000 requests per seconde op een simpele hello-world fixture. Router lookups duren ongeveer 51 nanoseconden op een configuratie met 500 routes. Async throughput ging 14× omhoog na de overstap naar multi-threaded Tokio met free-threaded CPython-ondersteuning.

Wat die cijfers voor jou betekenen: als je een API draait die duizenden requests per seconde verwerkt, stapelen die verbeteringen zich op. Lagere latency betekent minder wachten voor je gebruikers. Hogere throughput betekent dat je servers meer aankunnen. Maar het echte verhaal zit niet in de ruwe cijfers—het zit in wat je niet hoeft te beheren.

Geen uvicorn. Geen Gunicorn. Geen ASGI middleware stack om te debuggen als er om 3 uur 's nachts iets misgaat. De complete request pipeline leeft in Rust, en jouw Python code is... gewoon jouw code.

De architectuur: Python als uitzondering, niet als regel

Zo ziet het request-pad eruit: Kernel (epoll/io_uring) → Tokio connection manager → TLS via rustls → HTTP parsing via Hyper → Router (matchit radix trie) → Middleware chain (auth, CORS, rate-limiting) → Python boundary via PyO3 → Jouw handler → Rust serializer → Response.

Let op waar Python binnenkomt: pas op het punt waar je applicatielogica begint. Alles daarvoor—alles wat identiek draait voor elke request—is Rust.

Dit is een belangrijk onderscheid. De developer achter JustAPI hanteerde een simpele regel tijdens de ontwikkeling: als een feature in Rust geïmplementeerd kan worden, dan moet het in Rust geïmplementeerd worden. Niet "kan sneller in Rust"—kan geïmplementeerd worden in Rust. Python is gereserveerd voor de lijm tussen Rust-waarden en jouw handlers.

Het is een constraint die het hele project heeft gevormd en heeft geresulteerd in iets wezenlijk anders dan andere Python-frameworks die Rust-stukjes hebben aangemonteerd.

Wat dit betekent voor developer experience

Hier wordt het interessant voor startups en groeiende teams.

Je krijgt een compleet API-framework—HTTP/1.1 en HTTP/2, TLS, routing met parameters, JSON serialisatie, automatische OpenAPI-documentatie—met 30 regels code die er echt uitzien als Python:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Maar onder die vertrouwde oppervlakte draait een Rust-server die TLS afhandelt, verbindingen beheert en responses serialiseert zonder ooit naar Python over te schakelen. De developer experience blijft Pythonic. De runtime performance is Rust.

Voor teams die MVP's bouwen die later misschien moeten opschalen, is dit belangrijk. Je schrijft vandaag Python. Je krijgt Rust performance zonder iets te herschrijven wanneer je meer load moet aankunnen.

De AI-factor: een engineering partner, geen vervanging

Dit project is gebouwd met agentic AI als actieve deelnemer—niet als autocomplete, maar als engineering gids die hielp bij het ontwerpen van de architectuur, beslissingen omzette in code, bugs vond en tests schreef.

Dat is het waard om eerlijk over te praten, want het wordt steeds common en zelden transparant besproken.

De developer beschrijft de codebase in drie lagen: delen die hij volledig begrijpt, delen die hij goed genoeg begrijpt om te onderhouden, en delen die AI heeft geschreven en die hij heeft gereviewed en getest maar niet uit zijn hoofd zou kunnen reproduceren. Hij is open dat dit onderdeel is van hoe het project bestaat.

Ik denk dat dat de juiste framing is. AI-tools versnellen ontwikkeling op complexe projecten, en doen alsof dat niet zo is helpt niemand. De sleutel is begrijpen wat je bezit versus wat je hebt gedelegeerd—en eerlijk zijn over wat wat is.

De praktische conclusie

Frameworks zoals JustAPI vertegenwoordigen een verschuiving in hoe we nadenken over Python's rol in high-performance systemen. Python gaat nergens heen voor applicatielogica—de leesbaarheid en het ecosysteem zijn te waardevol. Maar de aanname dat het framework zelf in Python moet draaien, wordt uitgedaagd.

Of JustAPI jouw volgende framework wordt of een interessant experiment blijft, de onderliggende insight heeft waarde: kijk naar wat hetzelfde draait op elke request in je stack. Daar is waarschijnlijk Rust-thuis. De delen die veranderen? Houd die in de taal waar je team het meest productief in is.

De kloof tussen "werkt" en "werkt goed" wordt steeds kleiner. Je gebruikers zullen de architectuur niet opmerken, maar wel de latency.

Vooruitkijkend

JustAPI zit op versie 2.0.10 met gedocumenteerde features waaronder WebSockets, SSE, background tasks, een scheduler, database-toegang via SQLx, en operationele tooling zoals OpenTelemetry en Prometheus metrics. Het is beschikbaar op PyPI met wheels voor standaard Linux, macOS, Windows, en de free-threaded CPython 3.14t build.

De cijfers staan in de repository. De tests slagen. De failures zijn gedocumenteerd. Dit is het soort engineering-transparantie dat we meer zouden moeten aanmoedigen.

Als je Python API's bouwt en performance belangrijk is, is het het bekijken waard. De toekomst van Python webframeworks ziet er misschien anders uit dan wat je vandaag gebruikt.