¿Por qué FastAPI es rápido y cómo lo mantienes rápido?

Question

Accepted Answer

FastAPI es uno de los frameworks de Python más rápidos porque está construido sobre **Starlette** (un framework ASGI ligero) y es **async-native**, manejando eficientemente muchas solicitudes I/O-bound concurrentes. Pero mantenerlo rápido requiere usar async correctamente — el error más común es bloquear el event loop.

## Por qué es 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
```

El modelo async es la clave: mientras una solicitud espera una consulta de base de datos o una llamada API, el servidor maneja otras — proporcionando alto throughput para cargas de trabajo I/O-bound.

## La forma #1 de mantenerlo rápido: no bloquees el 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 es la única regla de rendimiento más importante: una llamada bloqueante dentro de `async def` bloquea todo el event loop, obligando a que las solicitudes se ejecuten una a la vez. Usa librerías async con `await`, o un `def` simple (se ejecuta en un thread pool).

## Mantener la velocidad — lista de verificación

```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 qué es importante

La velocidad de FastAPI es la razón principal por la que los equipos la eligen, pero lograr esa velocidad en la práctica depende de **usar async correctamente** — y la regla más importante, frecuentemente violada, es **nunca bloquees el event loop**.

Comprender *por qué* FastAPI es rápido (fundación ASGI async-native, concurrencia I/O eficiente, núcleo Pydantic v2 rápido) aclara que su ventaja de rendimiento se aplica a cargas de trabajo I/O-bound manejadas concurrentemente.

Saber cómo *mantenerlo* rápido es la habilidad práctica crítica: evitar el error devastador de poner llamadas bloqueantes en `async def` (lo que serializa todas las solicitudes detrás de un event loop congelado), usar librerías async en endpoints async (o `def` simple para código bloqueante), descargar trabajo de CPU, caching, optimizar la base de datos (frecuentemente el cuello de botella real), y ejecutar múltiples workers para múltiples cores.

Esta combinación — apalancando async correctamente y midiendo para encontrar cuellos de botella reales — es lo que te permite realizar el potencial de rendimiento de FastAPI, convirtiéndolo en conocimiento importante de nivel senior para construir APIs genuinamente rápidas y escalables en lugar de aquellas que parecen async pero funcionan como código bloqueante.