Por que FastAPI é rápido e como você o mantém assim?

Question

Accepted Answer

FastAPI é um dos frameworks Python mais rápidos porque é construído em **Starlette** (um framework ASGI leve) e é **nativo de async**, manipulando eficientemente muitas solicitações I/O-bound simultâneas. Mas mantê-lo rápido requer usar async corretamente — o erro mais comum é bloquear o event loop.

## Por que é rápido

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

O modelo async é a chave: enquanto uma solicitação aguarda uma consulta ao banco de dados ou chamada de API, o servidor lida com outras — fornecendo alta taxa de transferência para cargas de trabalho I/O-bound.

## A #1 forma de mantê-lo rápido: não bloqueie o 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()
```

Esta é a regra de desempenho mais importante: uma chamada bloqueante dentro de `async def` bloqueia todo o event loop, forçando as solicitações a serem executadas uma por vez. Use bibliotecas async com `await` ou uma simples `def` (executada em um thread pool).

## Mantendo-o rápido — a checklist

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

## Por que isso importa

A velocidade do FastAPI é uma razão primária pela qual as equipes a escolhem, mas alcançar essa velocidade na prática depende de **usar async corretamente** — e a regra mais importante, frequentemente violada, é **nunca bloqueie o event loop**.

Entender *por que* FastAPI é rápido (foundation async nativa de ASGI, concorrência de I/O eficiente, núcleo rápido do Pydantic v2) esclarece que sua vantagem de desempenho se aplica a cargas de trabalho I/O-bound manipuladas simultaneamente.

Saber como *mantê-lo* rápido é a habilidade prática crítica: evite o erro devastador de colocar chamadas bloqueantes em `async def` (o que serializa todas as solicitações atrás de um event loop congelado), use bibliotecas async em endpoints async (ou simples `def` para código bloqueante), descarregue trabalho de CPU, caching, otimize o banco de dados (frequentemente o verdadeiro gargalo), e execute múltiplos workers para múltiplos núcleos.

Esta combinação — aproveitar async corretamente e medir para encontrar verdadeiros gargalos — permite que você realize o potencial de desempenho do FastAPI, tornando-a conhecimento importante de nível sênior para construir APIs genuinamente rápidas e escaláveis em vez de aquelas que parecem async, mas funcionam como código bloqueante.