Hvorfor er FastAPI rask, og hvordan holder du det på den måten?

Question

Accepted Answer

FastAPI er blant de raskeste Python-rammeverka fordi det er bygget på **Starlette** (et lett ASGI-rammeverk) og er **async-native**, og håndterer effektivt mange samtidige I/O-bundne forespørsler. Men å holde det raskt krever å bruke async riktig — den vanligste feilen er å blokkere event loop-en.

## Hvorfor det er raskt

```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økkelen: mens en forespørsel venter på en database-spørring eller API-kall, håndterer serveren andre — noe som gir høyt gjennomstrømning for I/O-bundne arbeidsbelastninger.

## Den #1 måten å holde det raskt på: ikke blokker event loop-en

```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 viktigste ytelsesregelen: et blokkerende anrop inne i `async def` blokkerer hele event loop-en, og tvinger forespørsler til å kjøre én om gangen. Bruk async-biblioteker med `await`, eller vanlig `def` (kjøres i en tråd pool).

## Å holde det raskt — sjekklisten

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

FastAPI's hastighet er en primær grunn til at team velger det, men å oppnå den hastigheten i praksis avhenger av **å bruke async riktig** — og den viktigste, ofte brutt regelen er **aldri blokkere event loop-en**.

Å forstå *hvorfor* FastAPI er raskt (async-native ASGI-grunnlag, effektiv I/O-samtidighet, rask Pydantic v2-kjerne) klargjør at ytelsesfordelen gjelder I/O-bundne arbeidsbelastninger håndtert samtidig.

Å vite hvordan du *holder det* raskt er den kritiske praktiske ferdigheten: unngå den ødeleggende feilen med å plassere blokkerende anrop i `async def` (som serialiserer alle forespørsler bak en frossen event loop), bruke async-biblioteker i async-endepunkter (eller vanlig `def` for blokkerende kode), avlaste CPU-arbeid, caching, optimalisere databasen (ofte det virkelige flaskehalsen), og kjøre flere arbeidere for flere kjerner.

Denne kombinasjonen — bruke async riktig og måle for å finne virkelige flaskehalser — lar deg realisere FastAPI's ytelsespotensial, noe som gjør det til viktig kunnskap på seniornivå for å bygge genuint raske, skalerbare API-er i stedet for de som ser async ut men oppfører seg som blokkerende kode.