// the find
long2ice/fastapi-cache
fastapi-cache is a tool to cache fastapi response and function result, with backends support redis and memcached.
fastapi-cache2 is a decorator-based caching layer for FastAPI — slap @cache() on an endpoint or plain function and it memoizes the result in Redis, Memcached, DynamoDB, or in-process memory. It's for people who want response caching with proper HTTP semantics (ETag, 304s) without writing that plumbing themselves.
The decorator API is genuinely low-friction — one line between the route decorator and the function, no manual cache-key wiring for the common case. It handles conditional requests properly: injects Request/Response, sets Cache-Control/ETag, and returns 304 on If-None-Match matches, which most people skip when they roll their own caching. The Coder and KeyBuilder abstractions are a real escape hatch — you can swap JsonCoder for Pickle, or build cache keys from the request path/query instead of function args, without touching the decorator call sites. Backend-agnostic design means you can start with InMemoryBackend in dev and move to Redis in prod by changing one init call.
Correctness is quietly coupled to return type annotations — if an endpoint returns a Pydantic model but you forget the `-> SomeModel` annotation, cached hits come back as a bare dict instead of the model instance, and nothing warns you. InMemoryBackend only reaps expired entries when they're accessed again, so a key nobody re-requests just sits there forever — no sweep, no memory bound. There's no stampede protection: a check-then-set decorator means N concurrent requests on a cold key all fall through to the real function simultaneously. The Redis backend has a sharp gotcha where a shared client with decode_responses=True silently breaks deserialization, and the last push was mid-2025 — over a year stale against a FastAPI/Starlette ecosystem that moves faster than that.