Hvorfor er FastAPI hurtig, og hvordan holder du det hurtig?

Question

Accepted Answer

FastAPI er blandt de hurtigste Python-frameworks, fordi det er bygget på **Starlette** (et letvægts ASGI-framework) og er **async-native**, og håndterer effektivt mange samtidige I/O-bound-anmodninger. Men at holde det hurtigt kræver at bruge async korrekt — den mest almindelige fejl er at blokere event loop.

## Hvorfor det er hurtigt

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

Async-modellen er nøglen: mens en anmodning afventer en databaseforespørgsel eller API-kald, håndterer serveren andre — hvilket giver høj throughput til I/O-bound-arbejdsbelastninger.

## Den #1-vej til at holde det hurtigt: bloker ikke event loop

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

Dette er den eneste vigtigste ydelses regel: et blokering kald indeni `async def` blokerer hele event loop, hvilket tvinger anmodninger til at køre en ad gangen. Brug async-biblioteker med `await`, eller almindelig `def` (kør i en thread pool).

## At holde det hurtigt — tjeklisten

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

## Hvorfor det betyder noget

FastAPI's hastighed er hovedårsagen til, at teams vælger det, men at opnå den hastighed i praksis afhænger af **at bruge async korrekt** — og den vigtigste, ofte overtrådt regel er **aldrig at blokere event loop**.

At forstå *hvorfor* FastAPI er hurtig (async-native ASGI-grundlag, effektiv I/O-concurrency, hurtigt Pydantic v2-core) præciserer, at dets ydelses fordel gælder for I/O-bound-arbejdsbelastninger, der håndteres samtidigt.

At vide hvordan man *holder det* hurtigt er den kritiske praktiske kompetence: at undgå den ødelæggende fejl at sætte blokering kald i `async def` (som serialiserer alle anmodninger bag en frossen event loop), at bruge async-biblioteker i async-endepunkter (eller almindelig `def` til blokering kode), at aflaste CPU-arbejde, caching, at optimere database (ofte det rigtige flaskehals), og at køre flere workers til flere kerner.

Denne kombination — at udnytte async korrekt og måle for at finde rigtige flaskehalse — er hvad der tillader dig at realisere FastAPI's ydelses potentiale, hvilket gør det vigtig viden på seniorplan til at bygge virkelig hurtige, skalérbare APIs i stedet for dem der ser async ud, men præsterer som blokering kode.