Waarom is FastAPI snel, en hoe houd je het op die manier?

Question

Accepted Answer

FastAPI is één van de snelste Python frameworks omdat het is gebouwd op **Starlette** (een licht ASGI framework) en **async-native** is, waardoor het efficiënt veel gelijktijdige I/O-bound requests afhandelt. Maar om het snel te houden, moet je async correct gebruiken — de meest voorkomende fout is het blokkeren van de event loop.

## Waarom het snel is

```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
```

Het async model is de sleutel: terwijl één request op een databasequery of API-aanroep wacht, verwerkt de server anderen — wat hoge doorvoer oplevert voor I/O-bound workloads.

## De #1 manier om het snel te houden: blokkeer de event loop niet

```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()
```

Dit is de enige meest belangrijke performance regel: een blokkerende aanroep in `async def` blokkeert de hele event loop, waardoor requests één voor één moeten worden uitgevoerd. Gebruik async libraries met `await`, of plain `def` (uitgevoerd in een thread pool).

## Om het snel te houden — de 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
```

## Waarom het belangrijk is

FastAPI's snelheid is een primaire reden waarom teams het kiezen, maar het bereiken van die snelheid in de praktijk hangt af van **async correct gebruiken** — en de meest belangrijke, veelgeschonden regel is **nooit de event loop blokkeren**.

Het begrijpen van *waarom* FastAPI snel is (async-native ASGI foundation, efficiënte I/O concurrency, snelle Pydantic v2 core) maakt duidelijk dat het performance voordeel van toepassing is op I/O-bound workloads die gelijktijdig worden afgehandeld.

Weten hoe je het *snel* kunt houden, is de kritieke praktische vaardigheid: vermijd de verwoestende fout om blokkerende aanroepen in `async def` te plaatsen (wat alle requests achter een bevroren event loop serialiseert), async libraries gebruiken in async endpoints (of plain `def` voor blokkerende code), CPU-werk offloaden, caching, database optimaliseren (vaak het echte knelpunt), en meerdere workers voor meerdere cores uitvoeren.

Deze combinatie — async correct benutten en meten om echte bottlenecks te vinden — stelt je in staat FastAPI's performance-potentieel te realiseren, waardoor het belangrijk senior-level kennis wordt voor het bouwen van echt snelle, schaalbare API's in plaats van die er async uitzien maar zich gedragen als blokkerende code.