Hvornår skal du bruge async def i stedet for def til endpoints?

Question

IT Interview Practice · Accepted Answer

FastAPI understøtter både `async def` og almindelig `def` til path-operationer. Valget betyder noget for ydeevnen: brug **`async def`** når du kan `await` ikke-blokerende I/O, og almindelig **`def`** når din kode kalder blokerende (synkrone) operationer.

## De to former

```python
@app.get("/async")
async def async_endpoint():
    data = await fetch_from_api()        # await non-blocking I/O — efficient
    return data

@app.get("/sync")
def sync_endpoint():
    data = blocking_db_call()             # ordinary blocking code
    return data
```

## Hvordan FastAPI håndterer hver enkelt

```text
async def → runs on the main event loop. Efficient ONLY if you await non-blocking calls.
            ⚠️ A BLOCKING call inside async def blocks the WHOLE event loop → kills concurrency!
def       → FastAPI runs it in a THREAD POOL, so blocking code doesn't block the event loop.
            Safe for synchronous/blocking libraries.
```

## Beslutningsreglen

```python
# ✅ async def — when you can await async libraries (httpx, async DB drivers)
async def get_user():
    async with httpx.AsyncClient() as c:
        return await c.get(url)

# ✅ plain def — when using SYNCHRONOUS/blocking libraries (requests, sync ORM)
def get_user():
    return requests.get(url).json()       # blocking → FastAPI runs it in a thread

# ❌ THE DANGEROUS MISTAKE — blocking call inside async def
async def bad():
    return requests.get(url).json()       # blocks the event loop! Use `def` or an async client
```

Den kritiske regel: **sæt aldrig blokerende kald i `async def`** — det blokerer event-loopet og ødelægger concurrency. Brug enten et async-bibliotek med `await`, eller brug en almindelig `def` (som FastAPI sikkert kører i en thread pool).

## Hvorfor det betyder noget

Art at vælge korrekt mellem `async def` og `def` påvirker direkte din APIs ydeevne og concurrency, og at gøre det forkert er en almindelig, alvorlig fejl.

Hovedindsynet er, at **`async def` kun er fordelagtigt når du `await` ikke-blokerende operationer** — at sætte et blokerende kald (som det synkrone `requests`-bibliotek eller en blokerende database-driver) ind i en `async def` blokerer hele event-loopet, fryser alle samtidige anmodninger og ødelægger formålet med async.

Omvendt kører FastAPI på intelligent vis almindelige `def`-endpoints i en thread pool, så synkron/blokerende kode er sikker der.

At forstå denne regel — brug `async def` med virkelig async-biblioteker, brug almindelig `def` til blokerende kode, og bland aldrig blokerende kald ind i `async def` — er væsentligt for at skrive performant FastAPI-endpoints og undgå den subtile men ødelæggende fejl at utilsigtet serialisere alle anmodninger bag et blokeret event-loop.

De to former

Hvordan FastAPI håndterer hver enkelt

Beslutningsreglen

Hvorfor det betyder noget

Relaterede spørgsmål