FastAPI

This part treats FastAPI as a boundary-design framework, not just a quick way to expose endpoints. The important questions are where HTTP concerns stop, where services begin, how request-scoped resources are owned, and how Pydantic, SQLAlchemy, and asyncio fit together without collapsing into one layer.

Quick takeaway: using FastAPI well means keeping routes thin, wiring resources explicitly, owning request lifecycles, and preserving stable DTO contracts. The framework is most effective when HTTP concerns and application concerns stay separate.

The Questions to Anchor First

How much should a route know?

Mostly HTTP parsing, auth, and response contracts. Domain rules and commit policy should stay deeper inside.

What should dependencies do?

They should wire sessions, settings, and clients. They should not become a hidden business layer.

Where should security stop?

Separate credential parsing, principal restoration, and authorization policy so routes do not become oversized policy blobs.

Why learn ASGI and Uvicorn first?

FastAPI is not the server. If you do not understand scopes, receive/send events, workers, and lifespan, production behavior will stay opaque.

Does async make it fast automatically?

No. Blocking calls, validation cost, query shape, pool sizing, and serialization dominate most real bottlenecks.

Can anything go into `BackgroundTasks`?

No. Keep it for short in-process follow-up work. Durable or heavy work belongs in a queue and worker model.

How are websockets and streaming different?

They are not one-shot request/response paths. Connection lifetime, middleware behavior, timeouts, and shutdown rules all matter more.

How should real-time services be designed?

Plan auth on connect, room membership, disconnect cleanup, reconnect behavior, and multi-worker broadcast boundaries together.

What happens when there are multiple workers?

In-memory room managers stop being enough. You need to understand why Redis pub/sub or another external fan-out layer becomes necessary.

What makes reconnect reliable?

Reconnect is not only about retrying. It also needs a protocol version, event IDs, resume cursors, and clear server hello behavior.

What should tests prove?

Resource lifecycles, dependency overrides, transaction isolation, and response contracts are usually more important than route internals.

Where does observability start?

Connect OpenTelemetry, Sentry, and structured logging once at startup, then design request IDs, trace IDs, and sampling policy intentionally.

What changes behind a reverse proxy?

`root_path`, forwarded headers, readiness, and graceful shutdown become explicit operational concerns instead of local-only details.

Recommended Reading Order

1. ASGI and Uvicorn
2. Project Structure
3. Dependency Injection
4. Request/Response Modeling
5. Security and Auth
6. Lifespan and Testing
7. Background Tasks and Offloading
8. WebSockets, Streaming, and Middleware
9. WebSocket Practical Patterns
10. Redis Pub/Sub and Multi-worker Broadcast
11. Client Protocol and Reconnect
12. Proxy, Health, and Shutdown
13. Performance and Ops
14. Observability

Working Rules for Real Services

• Keep routes thin and transport-oriented.
• Separate the ASGI server's responsibilities from the FastAPI app's responsibilities.
• Do not collapse authn, authz, and business policy into the same dependency or route function.
• Do not collapse request DTOs, domain commands, ORM entities, and response DTOs into one type.
• Use lifespan or yield dependencies for resource ownership.
• Use BackgroundTasks only for short in-process follow-up work, not for durable or heavy jobs.
• Treat websockets and streaming as long-lived connection paths, not ordinary request handlers.
• Design WebSocket auth, room cleanup, and multi-worker broadcast strategy explicitly instead of treating them as incidental route details.
• Accept that room and broadcast architecture changes once you move from a single worker to multiple workers.
• Treat reconnect as a protocol problem involving versioning, event IDs, and resume rules, not only as a client retry loop.
• Treat reverse proxies, health endpoints, and graceful shutdown as explicit operational boundaries.
• Do not hide sync blocking work inside async endpoints.
• Look at query shape, serialization cost, pool contention, and observability before blaming framework overhead.
• Configure tracing, error monitoring, and structured logging once during app bootstrap.

Good Companion Chapters

• Asyncio
• Pydantic
• SQLAlchemy 2.0
• FastAPI + Pydantic + SQLAlchemy