Varför är FastAPI snabbt, och hur håller du det så?

Question

Accepted Answer

FastAPI är en av de snabbaste Python-ramverken eftersom det är byggt på **Starlette** (ett lättweight ASGI-ramverk) och är **async-native**, vilket hanterar många samtidiga I/O-bundna begäranden effektivt. Men för att hålla det snabbt krävs det att använda async korrekt — det vanligaste misstaget är att blockera event loop:en.

## Varför det är snabbt

```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 är nyckeln: medan en begäran väntar på en databasfråga eller API-anrop hanterar servern andra — vilket ger högt genomflöde för I/O-bundna arbetsbelastningar.

## Det #1 sättet att hålla det snabbt: blockera inte 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()
```

Detta är den enskilt viktigaste prestandaregeln: ett blockerande anrop inuti `async def` blockerar hela event loop:en, vilket tvingar begäranden att köras en åt gången. Använd async-bibliotek med `await`, eller en vanlig `def` (körs i en trådpool).

## Hålla det snabbt — checklistan

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

## Varför det är viktigt

FastAPI:s snabbhet är en primär anledning till att team väljer det, men att uppnå den hastigheten i praktiken beror på **att använda async korrekt** — och den viktigaste, ofta bruten regeln är **aldrig blockera event loop:en**.

Att förstå *varför* FastAPI är snabbt (async-native ASGI-grund, effektiv I/O-concurrency, snabb Pydantic v2-kärna) förtydligar att dess prestationsfördel gäller I/O-bundna arbetsbelastningar som hanteras samtidigt.

Att veta *hur* man håller det snabbt är den kritiska praktiska färdigheten: att undvika det förödande misstaget att lägga blockerande anrop i `async def` (vilket serialiserar alla begäranden bakom en frusen event loop), att använda async-bibliotek i async-slutpunkter (eller vanlig `def` för blockerande kod), att avlasta CPU-arbete, caching, optimera databasen (ofta den riktiga flaskhalsen), och att köra flera workers för flera kärnor.

Denna kombination — att på rätt sätt utnyttja async och mäta för att hitta riktiga flaskhalsar — är vad som låter dig inse FastAPI:s prestandapotential, vilket gör det till viktigt kunskapsområde på seniorsnivå för att bygga genuint snabba, skalbara API:er istället för sådana som ser async ut men presterar som blockerande kod.