JustAPI : quand le framework Python vit dans Rust

Une question m'a trotté dans la tête après avoir testé ce projet : pourquoi ton framework web Python passe-t-il autant de temps à faire des trucs qui n'ont rien à voir avec ton code ?

Regarde le chemin typique : FastAPI repose sur Starlette, qui repose sur uvicorn, qui gère une boucle d'événements asyncio. Chaque requête — avant même d'arriver à ta logique métier — traverse plusieurs couches Python, déclenche de la sérialisation en Python, et passe par du code qui fonctionne exactement de la même façon pour toutes les requêtes.

Et si ça changeait ? Et si le framework — cette partie qui fait un travail identique quel que soit ton application — vivait entièrement en Rust, et que Python ne tournait que là où ton code est vraiment unique ?

C'est le pari de JustAPI. Après l'avoir testé, je pense que ça vaut le coup de comprendre pas juste ce que ça fait, mais pourquoi les choix d'architecture comptent pour ton prochain projet.

Les perfs, ce n'est pas ce que tu crois

Commençons par les chiffres, parce qu'une promesse de performance sans contexte, c'est du marketing.

Le projet atteint 766 000 requêtes par seconde sur un test hello-world basique. Le routeur fait ses recherches en environ 51 nanosecondes sur une config de 500 routes. Le débit async a été multiplié par 14 après le passage à un Tokio multi-threadé avec support du CPython free-threaded.

Ce que ça veut dire concrètement : si tu gères une API qui traite des milliers de requêtes par seconde, ces améliorations s'additionnent. Latence plus basse, les utilisateurs attendent moins. Débit plus élevé, tes serveurs encaissent plus de charge. Mais le vrai intérêt n'est pas dans les chiffres bruts — c'est ce que tu n'as plus à gérer.

Pas de uvicorn. Pas de Gunicorn. Pas de pile middleware ASGI à débugger à 3h du matin quand quelque chose merde. Tout le pipeline de requête vit dans Rust, et ton code Python, ben... c'est juste ton code.

L'architecture : Python comme exception, pas comme règle

Le chemin d'une requête chez JustAPI :

Kernel (epoll/io_uring) → Gestionnaire de connexion Tokio → TLS via rustls → Parsing HTTP via Hyper → Routeur (radix trie matchit) → Chaîne middleware (auth, CORS, rate-limiting) → Frontière Python via PyO3 → Ton handler → Sérialiseur Rust → Réponse

Regarde où Python intervient : uniquement au point où ta logique applicative commence. Tout le reste — tout ce qui tourne de façon identique pour chaque requête — c'est du Rust.

C'est une distinction importante. Le développeur de JustAPI s'est imposé une règle simple : si une fonctionnalité peut être implémentée en Rust, elle doit être implémentée en Rust. Pas "peut être plus rapide en Rust" — peut être implémentée en Rust. Python est réservé pour le collage entre les valeurs Rust et tes handlers.

C'est une contrainte qui a façonné tout le projet et qui donne quelque chose de vraiment différent des autres frameworks Python qui ont ajouté des morceaux de Rust par-dessus.

Ce que ça change pour l'expérience développeur

Voilà où cette approche devient intéressante pour les startups et les équipes en croissance.

Tu obtiens un framework API complet — HTTP/1.1 et HTTP/2, TLS, routage avec paramètres, sérialisation JSON, documentation OpenAPI automatique — avec 30 lignes de code qui ressemblent vraiment à du Python :

from justapi import JustAPIApp

app = JustAPIApp()

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

app.run()

Mais dessous cette surface familière, tu fais tourner un serveur Rust qui gère le TLS, les connexions et sérialise les réponses sans jamais passer par Python. L'expérience développeur reste Pythonique. La performance runtime, c'est du Rust.

Pour les équipes qui construisent des MVP susceptibles de devoir scale plus tard, c'est important. Tu codes en Python aujourd'hui. Tu obtiens des perfs Rust sans rien réécrire quand tu dois gérer plus de charge.

Le facteur IA : un partenaire d'ingénierie, pas un remplaçant

Ce projet a été construit avec une IA agentique comme participant actif — pas comme autocomplétion, mais comme guide d'ingénierie qui a aidé à concevoir l'architecture, traduire les décisions en code, trouver des bugs et écrire des tests.

Ça mérite d'être discuté honnêtement, parce que c'est de plus en plus courant et rarement abordé de façon transparente.

Le développeur décrit sa codebase en trois niveaux : des parties qu'il comprend complètement, des parties qu'il comprend assez bien pour maintenir, et des parties écrites par l'IA qu'il a reviewées et testées mais qu'il ne pourrait pas reproduire de mémoire. Il est clair que c'est comme ça que le projet existe.

Je pense que c'est la bonne approche. Les outils IA accélèrent le développement sur des projets complexes, et faire semblant du contraire n'aide personne. La clé, c'est de comprendre ce qu'on possède réellement versus ce qu'on a délégué — et d'être honnête sur la différence.

Le constat pratique

Des frameworks comme JustAPI représentent un changement dans notre façon de voir le rôle de Python dans les systèmes haute performance. Python ne va pas disparaître pour la logique applicative — sa lisibilité et son écosystème sont trop précieux. Mais l'idée que le framework lui-même doit tourner en Python est en train d'être remise en question.

Que JustAPI devienne ton prochain framework ou reste une expérience intéressante, l'idée sous-jacente a de la valeur : regarde ce qui tourne de la même façon sur chaque requête dans ta stack. C'est probablement du territoire Rust. Les parties qui changent ? Garde-les dans le langage où ton équipe est la plus productive.

L'écart entre "ça marche" et "ça marche bien" ne cesse de se réduire. Tes utilisateurs ne verront pas l'architecture, mais ils verront la latence.

Où on en est

JustAPI en est à la version 2.0.10 avec des fonctionnalités documentées : WebSockets, SSE, tâches en arrière-plan, scheduler, accès base de données via SQLx, et outils opérationnels comme OpenTelemetry et métriques Prometheus. C'est dispo sur PyPI avec des wheels pour Linux, macOS, Windows et le build CPython 3.14t free-threaded.

Les chiffres sont dans le dépôt. Les tests passent. Les échecs sont documentés. C'est le genre de transparence d'ingénierie qu'on devrait encourager davantage.

Si tu construis des API Python et que les perfs comptent pour toi, ça vaut le détour. L'avenir des frameworks web Python ne ressemblera peut-être pas à ce que tu utilises aujourd'hui.