JustAPI: Wenn Rust den Framework-Kram übernimmt und Python nur noch das tut, was zählt

Die Frage, die einen Entwickler lange beschäftigt hat: Warum verbringt dein Python-Framework so viel Zeit mit Dingen, die nichts mit deinem Code zu tun haben?

Schauen wir uns die Stack-Landschaft an. FastAPI baut auf Starlette auf, das wiederum auf uvicorn läuft, das einen asyncio Event Loop orchestriert. Jede Anfrage – bevor sie überhaupt deine Business-Logik erreicht – überquert mehrere Python-Grenzen, löst Serialisierung in Python aus und wird durch Code geroutet, der für jede einzelne Anfrage identisch läuft.

Was wäre, wenn sich das ändern würde? Was, wenn der Framework-Teil – also das, was unabhängig von deiner Anwendung immer gleich läuft – komplett in Rust existiert, und Python nur noch den Code ausführt, der wirklich spezifisch für das ist, was du baust?

Genau das ist die Idee hinter JustAPI.

Performance-Zahlen mit Substanz

Bevor wir in die Architektur einsteigen: Ein paar Zahlen, denn nackte Performance-Versprechen ohne Kontext sind Marketing, keine Ingenieurskunst.

Das Projekt schafft 766.000 Requests pro Sekunde bei einem simplen Hello-World-Test. Der Router liefert Lookups in etwa 51 Nanosekunden bei einer 500-Routen-Konfiguration. Der Async-Durchsatz verbesserte sich um das 14-fache nach dem Umstieg auf multi-threaded Tokio mit free-threaded CPython-Support.

Was bedeuten diese Zahlen für dich? Wenn du eine API betreibst, die Tausende Anfragen pro Sekunde verarbeitet, vervielfachen sich diese Gewinne. Weniger Latenz bedeutet: Benutzer warten kürzer. Höherer Durchsatz bedeutet: Server stemmen mehr Last.

Aber die eigentliche Geschichte sind die Dinge, die du nicht mehr verwalten musst. Kein uvicorn. Kein Gunicorn. Kein ASGI-Middleware-Stack zum Debuggen, wenn um 3 Uhr nachts etwas schiefläuft. Die komplette Request-Pipeline existiert in Rust, und dein Python-Code ist einfach nur... dein Code.

Architektur: Python als Ausnahme, nicht als Standard

Der Request-Pfad sieht so aus: Kernel (epoll/io_uring) → Tokio Connection Manager → TLS via rustls → HTTP-Parsing via Hyper → Router (matchit radix trie) → Middleware-Kette (Auth, CORS, Rate-Limiting) → Python-Grenze via PyO3 → Dein Handler → Rust-Serialisierung → Response.

Beachte, wo Python ins Spiel kommt: erst an dem Punkt, an dem deine Anwendungslogik beginnt. Alles davor – alles, was für jede Anfrage identisch läuft – ist Rust.

Das ist eine wichtige Unterscheidung. Der Entwickler von JustAPI hat sich während der Entwicklung eine einfache Regel auferlegt: Wenn ein Feature in Rust implementiert werden kann, dann muss es in Rust implementiert werden. Nicht „kann in Rust schneller sein" – sondern „kann in Rust implementiert werden". Python bleibt für die Klebstoff-Schicht zwischen Rust-Werten und deinen Handlern reserviert.

Eine Einschränkung, die das gesamte Projekt geprägt hat und etwas hervorbrachte, das sich genuin von anderen Python-Frameworks unterscheidet, die Rust-Teile einfach nur draufgepfropft bekommen haben.

Developer Experience: Vertraut fühlen, Rust-Performance bekommen

Hier wird es spannend für Startups und wachsende Teams.

Du bekommst ein vollständiges API-Framework – HTTP/1.1 und HTTP/2, TLS, Routing mit Parametern, JSON-Serialisierung, automatische OpenAPI-Dokumentation – mit 30 Zeilen Code, die tatsächlich wie Python aussehen:

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Aber unter dieser vertrauten Oberfläche läuft ein Rust-Server, der TLS handhabt, Verbindungen verwaltet und Responses serialisiert, ohne jemals in Python-Land überzutreten. Die Developer Experience bleibt Pythonic. Die Runtime-Performance ist Rust.

Für Teams, die MVPs bauen, die später skalieren müssen, ist das relevant. Du schreibst heute Python. Du bekommst Rust-Performance, ohne etwas umschreiben zu müssen, wenn du mehr Last bewältigen musst.

Der AI-Faktor: Ein Engineering-Partner, kein Ersatz

Dieses Projekt wurde mit agentic AI als aktivem Teilnehmer gebaut – nicht als Autocomplete, sondern als Engineering-Leitfaden, der bei der Architektur-Design half, Entscheidungen in Code umsetzte, Bugs fand und Tests schrieb.

Das lohnt eine ehrliche Diskussion, denn es wird immer häufiger und selten transparent kommuniziert.

Der Entwickler beschreibt die Codebase in drei Stufen: Teile, die er vollständig versteht; Teile, die er gut genug versteht, um sie zu pflegen; und Teile, die AI geschrieben hat, die er überprüft und getestet hat, aber nicht aus dem Gedächtnis reproduzieren könnte. Er ist offen, dass das Teil davon ist, wie das Projekt existiert.

Das ist der richtige Rahmen. AI-Tools beschleunigen die Entwicklung an komplexen Projekten, und so zu tun, als wäre das nicht der Fall, hilft niemandem. Der Schlüssel liegt darin zu verstehen, was du besitzt, versus was du delegiert hast – und ehrlich zu sein, was was ist.

Der praktische Mehrwert

Frameworks wie JustAPI repräsentieren einen Shift darin, wie wir über Pythons Rolle in Hochleistungssystemen denken. Python wird nicht verschwinden – für Anwendungslogik sind Lesbarkeit und Ökosystem zu wertvoll. Aber die Annahme, dass das Framework selbst in Python laufen muss, wird hinterfragt.

Ob JustAPI dein nächstes Framework wird oder ein interessantes Experiment bleibt – die zugrundeliegende Einsicht hat Wert: Schau dir an, was in deinem Stack bei jeder Anfrage gleich läuft. Das ist wahrscheinlich Rust-Territorium. Die Teile, die sich ändern? Die behältst du in der Sprache, in der dein Team am produktivsten ist.

Die Lücke zwischen „funktioniert" und „funktioniert gut" wird kleiner. Deine Benutzer werden die Architektur nicht bemerken – aber die Latenz.

Blick nach vorn

JustAPI steht bei Version 2.0.10 mit dokumentierten Features wie WebSockets, SSE, Background Tasks, einem Scheduler, Datenbankzugriff via SQLx und operationalem Tooling wie OpenTelemetry und Prometheus Metrics. Verfügbar auf PyPI mit Wheels für standard Linux, macOS, Windows und das free-threaded CPython 3.14t Build.

Die Zahlen liegen im Repository. Die Tests laufen. Die bekannten Probleme sind dokumentiert. Das ist die Art von Engineering-Transparenz, die wir öfter sehen sollten.

Wenn du Python-APIs baust und Performance relevant für dich ist: Ein Blick lohnt sich. Die Zukunft von Python-Webframeworks könnte anders aussehen als das, was du heute nutzt.