Dlaczego FastAPI jest szybki i jak go w takim stanie utrzymać?

Question

Accepted Answer

FastAPI jest jedną z najszybszych frameworków Pythona, ponieważ jest zbudowany na **Starlette** (lekkim frameworku ASGI) i jest **native'em asynchronicznym**, efektywnie obsługując wiele jednoczesnych żądań I/O-bound. Ale aby go utrzymać szybkim, musisz prawidłowo używać async — najczęstszym błędem jest blokowanie event loop.

## Dlaczego jest szybki

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

Model asynchroniczny jest kluczem: podczas gdy jedno żądanie czeka na zapytanie do bazy danych lub wywołanie API, serwer obsługuje inne — dając wysoki przepustowość dla obciążeń I/O-bound.

## #1 sposób na utrzymanie szybkości: nie blokuj 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()
```

To jest najważniejsza reguła wydajności: blokujące wywołanie wewnątrz `async def` blokuje cały event loop, zmuszając żądania do uruchamiania jeden po drugim. Używaj bibliotek asynchronicznych z `await` lub zwykłego `def` (uruchamianego w thread pool).

## Utrzymanie szybkości — lista kontrolna

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

## Dlaczego to ważne

Szybkość FastAPI jest głównym powodem, dla którego zespoły go wybierają, ale osiągnięcie tej szybkości w praktyce zależy od **prawidłowego używania async** — a najważniejszą, często naruszaną regułą jest **nigdy nie blokuj event loop**.

Zrozumienie *dlaczego* FastAPI jest szybki (natywna podstawa ASGI async, efektywna współbieżność I/O, szybkie jądro Pydantic v2) wyjaśnia, że jego przewaga wydajności dotyczy obciążeń I/O-bound obsługiwanych współbieżnie.

Wiedza o tym, jak go *utrzymać* szybkim, jest krytyczną praktyczną umiejętnością: unikaj katastrofalnego błędu umieszczania blokujących wywołań w `async def` (co serializuje wszystkie żądania za zamarzniętym event loop), używaj bibliotek asynchronicznych w asynchronicznych punktach końcowych (lub zwykłego `def` dla kodu blokującego), przesuń pracę CPU, caching, optymalizuj bazę danych (często rzeczywiste wąskie gardło) i uruchamiaj wielu pracowników na wiele rdzeni.

Ta kombinacja — prawidłowe wykorzystanie async i pomiar w celu znalezienia rzeczywistych wąskich gardeł — pozwala ci zrealizować potencjał wydajności FastAPI, co stanowi ważną wiedzę na poziomie seniora do budowania rzeczywiście szybkich, skalowalnych interfejsów API zamiast tych, które wyglądają asynchronicznie, ale działają jak kod blokujący.