π¦ Implement Caching for Todos API Responses (Including Search Queries)
π Overview
The todos API currently performs a (fake) database read for every request, including when fetching or searching todos. Add an API response caching layer to reduce latency and database load, and to improve user experience for repeated queries. Caching must include responses for list and search queries.
π― Acceptance Criteria
Nice to Have
π§ Technical Requirements
- Use a caching solution such as node-cache, lru-cache, or a tool like Redis (integration optional for now)
- Key cache by endpoint and query string, e.g.
/api/todos?search=foo
- Trim and encode user input to create the cache key
- Set TTL for cache entries (configurable in env or code)
- No caching for POST/PUT/PATCH/DELETE responses
π« Out of Scope
- Do not implement distributed or cloud cache (start with local memory)
- No user-level or per-session customizations for caching
- Cache update/invalidation after data mutations is optional
β
Getting Started
- Install a small caching library:
- Implement cache-lookup logic in the relevant API route handlers before database queries.
- Cache should key responses by both URL and query parameters.
- (Nice to have) On POST/PUT/PATCH/DELETE to todos, invalidate or update affected cache keys.
- Make cache TTL easily configurable.
π Resources
π¦ Implement Caching for Todos API Responses (Including Search Queries)
π Overview
The todos API currently performs a (fake) database read for every request, including when fetching or searching todos. Add an API response caching layer to reduce latency and database load, and to improve user experience for repeated queries. Caching must include responses for list and search queries.
π― Acceptance Criteria
/api/todosand/api/todos?search=...are cachedNice to Have
π§ Technical Requirements
/api/todos?search=fooπ« Out of Scope
β Getting Started
π Resources