fastapi-pro
FastAPI guidance — typed endpoints, Pydantic validation, dependency injection, async patterns, and production deployment.
- License 许可
- MIT
- 最近更新
- 2026-11-07
- Stars
- ★ 0
- Forks
- 1
01 前言 Front Matter
- name
- fastapi-pro
- category
- development
- description
- FastAPI guidance — typed endpoints, Pydantic validation, dependency injection, async patterns, and production deployment.
03 SKILL.md 正文
Overview
FastAPI is a modern Python web framework built on Starlette and Pydantic, where type annotations double as request validation, serialization, and automatic OpenAPI documentation. Declare a Pydantic model and you get parsing, validation errors, and interactive docs for free. Its native async support makes it a strong default for I/O-bound Python APIs. This skill covers designing FastAPI services well: dependency injection, background work, database patterns, and production deployment.
When to use
- Building a typed, documented REST API in Python.
- Designing dependency injection (DB sessions, auth, settings) the FastAPI way.
- Mixing async endpoints with sync libraries (SQLAlchemy, boto3) safely.
- Generating OpenAPI clients or serving interactive docs.
- Deploying FastAPI behind a production ASGI server.
- Adding WebSockets or SSE to a Python API.
- Structuring a large FastAPI codebase across teams.
Core concepts
- Types are the contract. Annotations on path params, query params, and Pydantic request/response models produce validation and docs automatically. Use
response_modelto strip internal fields — never return ORM objects directly. - Dependency injection with
Depends. Dependencies are reusable, composable functions:get_db(),get_current_user(), settings. They can yield (setup/teardown), be cached per-request, and nested. This is the framework's extension mechanism — prefer it over globals and middleware for request-scoped needs. - Async done right.
async defendpoints run on the event loop; call async libraries withawait. Blocking sync code (most ORMs' sync APIs,requests, heavy CPU work) insideasync defendpoints stalls every request — run it in a threadpool viaanyio.to_threador usedefendpoints and let FastAPI thread them. - Pydantic v2. Models validate on assignment optionally, serialize fast, and support strict types, custom validators, and
computed_field. Keep validation logic in models, not in route handlers. - Routers and versioning.
APIRouterwith prefixes and tags organizes large APIs; version via URL prefix (/v1) from the start if the API is public. - BackgroundTasks vs workers.
BackgroundTasksrun after the response is sent — fine for quick post-response work (sending an email). Anything slow, retryable, or critical belongs in a real queue (Celery, arq, Dramatiq). - Lifespan events. The modern
lifespancontext manager (replacingon_event) handles startup/shutdown: connect pools, load models, then yield; cleanup after. One place for resource lifecycle. - Middleware vs dependencies. Middleware sees every request (good for logging, CORS, request IDs); dependencies are opt-in per endpoint (good for auth, DB). Don't implement auth as middleware when only some routes need it.
- Response classes.
JSONResponsedefault;StreamingResponsefor large/streaming payloads;FileResponsefor downloads — pick deliberately, and set media types explicitly. - OpenAPI customization. Operation IDs, tags, and descriptions shape generated clients; callbacks and webhooks document async flows; keep the schema clean because it becomes your public contract.
Practical workflow
- Scaffold the project. Separate API, domain, and infrastructure:
app/ main.py # app factory, router mounting, middleware api/v1/ # routers schemas/ # Pydantic models (request/response) services/ # business logic core/ # settings, security, dependencies - Define the app factory. Build the app in a
create_app()function so tests can construct isolated instances; configure CORS, trusted hosts, and exception handlers there.def create_app() -> FastAPI: app = FastAPI(title="Shop API", lifespan=lifespan) app.include_router(api_router, prefix="/v1") app.add_middleware(RequestIDMiddleware) return app - Write typed endpoints. Request model in, response model out, dependencies declared:
@router.post("/users", response_model=UserOut, status_code=201) def create_user(payload: UserCreate, db: Session = Depends(get_db)): ...- Keep handlers thin: validate → authorize → call service → return. No SQL in route functions.
- Manage DB sessions. A
get_dbdependency that yields a session and closes it infinally— one session per request, committed or rolled back by the service layer, never shared across requests. - Secure and observe. JWT/OAuth2 via
fastapi.security, rate limiting at the proxy, structured logging with request IDs, and/healthplus/readyendpoints.- Use
HTTPBearer/OAuth2PasswordBearerschemes so the OpenAPI docs show an Authorize button.
- Use
- Test properly.
TestClient(or asynchttpx.AsyncClientwith ASGI transport) for endpoint tests; override dependencies (app.dependency_overrides) to inject test doubles for DB/auth. - Handle file uploads safely.
UploadFilewith size limits, content-type validation, and streaming to storage — never buffer multi-GB uploads in memory. - Deploy. Serve with uvicorn workers (or gunicorn + uvicorn workers) behind nginx/traefik; set worker count ≈ 2×CPU cores for sync endpoints, fewer for pure-async; configure timeouts and graceful shutdown.
Common pitfalls
- Blocking the event loop — calling sync DB drivers or
time.sleepinasync defendpoints; profile under load to catch it. - Returning ORM models directly — lazy loading triggers N+1 queries during serialization; always map to Pydantic response models.
- Leaking DB sessions — a
get_dbwithouttry/finallyclose exhausts the connection pool under traffic. - Putting heavy work in BackgroundTasks — they share the worker process; a slow task starves request handling. Use a queue.
- No request size limits — huge JSON bodies can OOM workers; set limits at the server/proxy and validate payload sizes.
- Docs exposed in production —
/docsand/openapi.jsonare great in dev; restrict or disable them on public deployments if they reveal internals. - Mutable default arguments in dependencies — classic Python gotcha, amplified because dependencies run per request.
- CORS misconfiguration —
allow_origins=["*"]with credentials; be explicit about origins in production. - Ignoring
response_model_exclude_unset— PATCH endpoints overwriting fields with defaults; useexclude_unsetfor partial updates. - No timeout on outgoing calls —
httpxwithout timeouts hanging workers; set timeouts on every external call. - Sync
TestClienthiding async bugs — portal-based TestClient can mask event-loop issues; test async paths with a real ASGI transport too. - Over-eager
response_modelnesting — deeply nested response models with N+1-prone computed fields; profile serialization on list endpoints. - Forgetting
dependencies=[...]on routers — auth applied per-endpoint instead of once on the router; include shared deps atinclude_routertime.
04 同仓库更多 Skills
web-scrape
Turn web pages into LLM-ready markdown via the Firecrawl API (renders JS, anti-bot handling). Use when browser_open/fetch fails on JS-heavy pages, or when you need clean markdown/structured extraction from a site. Requires FIRECRAWL_API_KEY.
design-taste-frontend
tasteskill v2, the anti-slop frontend skill. Art direction for websites, distilled from a study of 247 curated gallery sites (One Page Love, Awwwards Sites of the Day). Deals researched directions (idea, composition, type, palette, photographs, section blueprints) from a library, enforces a strict no-slop house style with a real-browser inspector, and runs a look-and-fix loop on screenshots. Use this whenever you build, design, redesign, restyle, polish or review a landing page, marketing site, portfolio, product page, one-pager, hero or any public-facing web page, in any stack (HTML/CSS, React, Next.js, Vue, Svelte, Astro, Tailwind) — also when the user says a page looks generic, templated, "AI-made", sloppy, or asks to make it look designed, premium, award-level or less like every other site. Not for dashboards or app screens.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).