Pourquoi FastAPI est-il rapide et comment le maintenir ainsi ?

Question

Accepted Answer

FastAPI figure parmi les frameworks Python les plus rapides car il est construit sur **Starlette** (un framework ASGI léger) et est **async-native**, gérant efficacement de nombreuses requêtes I/O-bound concurrentes. Mais le maintenir rapide nécessite d'utiliser async correctement — l'erreur la plus courante est de bloquer la boucle d'événements.

## Pourquoi c'est rapide

```text
✓ ASGI + Starlette — a modern async foundation (vs older WSGI sync frameworks)
✓ Async-native — one process handles thousands of concurrent I/O-bound requests
  by overlapping wait times, instead of one-at-a-time
✓ Pydantic v2 — validation/serialization core is now in Rust (very fast)
✓ Minimal overhead per request
```

Le modèle async est la clé : tandis qu'une requête attend une requête de base de données ou un appel API, le serveur gère les autres — offrant un débit élevé pour les workloads I/O-bound.

## Le #1 moyen de le maintenir rapide : ne pas bloquer la boucle d'événements

```python
# ❌ blocking call inside async def → freezes the event loop, serializing ALL requests
@app.get("/bad")
async def bad():
    return requests.get(url).json()       # SYNC/blocking → kills concurrency

# ✅ use an async client and await it
@app.get("/good")
async def good():
    async with httpx.AsyncClient() as c:
        return (await c.get(url)).json()  # non-blocking

# ✅ OR use a plain def — FastAPI runs it in a thread pool (safe for blocking code)
@app.get("/also-good")
def also_good():
    return requests.get(url).json()
```

C'est la règle de performance la plus importante : un appel bloquant à l'intérieur de `async def` bloque toute la boucle d'événements, forçant les requêtes à s'exécuter une à la fois. Utilisez des bibliothèques async avec `await`, ou une simple `def` (exécutée dans un thread pool).

## Maintenir la rapidité — la checklist

```text
✓ Use async DB drivers / async libraries (httpx, asyncpg) in async endpoints
✓ Run blocking code in plain def (thread pool) or via run_in_executor
✓ Avoid heavy CPU work on the event loop → offload to workers/processes
✓ Add caching (Redis) for expensive repeated work
✓ Optimize the database (fix N+1, add indexes) — often the real bottleneck
✓ Run multiple worker processes (uvicorn/gunicorn workers) to use all CPU cores
✓ Use connection pooling; paginate large results
✓ MEASURE first (profiling, load testing) — fix the actual bottleneck
```

## Pourquoi c'est important

La rapidité de FastAPI est une raison principale pour laquelle les équipes la choisissent, mais réaliser cette rapidité en pratique dépend de l'**utilisation correcte de async** — et la règle la plus importante et fréquemment violée est de **ne jamais bloquer la boucle d'événements**.

Comprendre *pourquoi* FastAPI est rapide (fondation ASGI async-native, concurrence I/O efficace, cœur Pydantic v2 rapide) clarifie que son avantage en performance s'applique aux workloads I/O-bound gérés de manière concurrente.

Savoir comment le *maintenir* rapide est la compétence pratique critique : éviter l'erreur dévastatrice de placer des appels bloquants dans `async def` (qui sérialise toutes les requêtes derrière une boucle d'événements gelée), utiliser des bibliothèques async dans les endpoints async (ou une simple `def` pour le code bloquant), décharger le travail CPU, mettre en cache, optimiser la base de données (souvent le vrai goulot d'étranglement), et exécuter plusieurs workers pour plusieurs cœurs.

Cette combinaison — exploiter async correctement et mesurer pour trouver les vrais goulots d'étranglement — est ce qui vous permet de réaliser le potentiel de performance de FastAPI, ce qui en fait une connaissance importante de niveau senior pour construire des APIs réellement rapides et évolutives plutôt que celles qui semblent async mais performent comme du code bloquant.