¿Cómo funciona el ciclo de vida de una petición en FastAPI?

Question

IT Interview Practice · Accepted Answer

FastAPI se ejecuta sobre **ASGI**, por lo que una petición atraviesa un pipeline asíncrono: el servidor ASGI la acepta, el middleware la envuelve, el router hace coincidir una ruta, **se resuelven las dependencias**, se ejecuta tu path operation y el valor de retorno se serializa en la respuesta.

## Las etapas

```
uvicorn (ASGI server)
   │  scope + receive/send
   ▼
ASGI / Starlette middleware  ── (CORS, GZip, custom)
   ▼
Routing  ── coincide method + path → path operation
   ▼
Dependencies (Depends)  ── resuelve sub-deps, security, yield-setup
   ▼
Path operation function  ── se ejecuta tu handler
   ▼
Response model  ── valida + serializa a JSON
   ▼
Background tasks  ── se ejecuta tras enviar la respuesta
   ▼
Response ──▶ client
```

1. **El servidor ASGI** (uvicorn/hypercorn) acepta la conexión y pasa a la app un `scope` y los callables `receive`/`send`.
2. **El middleware** se ejecuta de fuera hacia dentro a la entrada y de dentro hacia fuera a la salida (`BaseHTTPMiddleware` o middleware ASGI puro). CORS, GZip y el timing personalizado viven aquí.
3. **El routing** hace coincidir el método HTTP + la ruta con una path operation; los parámetros de path/query/body los extrae y valida **Pydantic**.
4. **La inyección de dependencias** — `Depends(...)` resuelve cada dependencia (sesión de BD, usuario actual, settings), cacheándola dentro de la petición. Una dependencia con `yield` ejecuta el setup antes y el teardown después del handler.
5. **La path operation** — tu `async def` (o `def`, ejecutado en un threadpool) ejecuta la lógica de negocio.
6. **La respuesta** — el valor de retorno se ajusta al `response_model` declarado, se valida y se serializa a JSON; se aplican el código de estado y las cabeceras.
7. **Las background tasks** registradas mediante `BackgroundTasks` se ejecutan *después* de enviar la respuesta.

```python
from fastapi import FastAPI, Depends, Request

app = FastAPI()

@app.middleware("http")
async def timing(request: Request, call_next):   # 2. middleware
    response = await call_next(request)
    response.headers["X-Time"] = "..."
    return response

async def get_db():                               # 4. dependencia (yield)
    db = Session()
    try:
        yield db
    finally:
        db.close()

@app.get("/items/{id}")                           # 3. routing
async def read_item(id: int, db=Depends(get_db)): # 5. handler
    return db.get(Item, id)                        # 6. serializado vía response_model
```

Las excepciones son capturadas por **exception handlers** (`@app.exception_handler(...)` / `HTTPException`), que las convierten en respuestas en lugar de hacer caer la petición.

## Por qué es importante

El ciclo de vida de la petición es donde ocurren realmente las características estrella de FastAPI: la E/S asíncrona, la validación con Pydantic y la inyección de dependencias se enganchan todas en etapas concretas. Conocer el orden — middleware, luego routing, luego dependencias, luego handler, luego serialización — te permite colocar la lógica transversal en el lugar correcto (auth como dependencia, timing como middleware, limpieza en una dependencia con `yield`), depurar por qué un error de validación o de auth se dispara antes de que tu código se ejecute, y evitar bloquear el event loop dentro de un handler asíncrono.

Las etapas

Por qué es importante

Preguntas relacionadas