[FEAT] API response caching layer — Redis/in-memory cache for GitHub API calls with TTL and invalidation

[IshitaSingh0822]

Summary

All GitHub API calls (contributions, PRs, repos, streak) are fetched fresh on every dashboard load.
With no caching, heavy users hit GitHub's 5,000 req/hr rate limit quickly and dashboard loads are slow.
Add a server-side caching layer with configurable TTL and manual invalidation.

Problem

• Every page load fires 4–5 GitHub API requests per user
• No deduplication if multiple tabs are open
• Rate limit errors surface as broken widgets with no recovery path
• Cold dashboard load can take 3–5s on slow connections

Proposed Solution

Implement an in-memory LRU cache (or Supabase table as fallback) for API route responses:

Route	Suggested TTL
/api/metrics/contributions	10 minutes
/api/metrics/prs	15 minutes
/api/metrics/repos	15 minutes
/api/metrics/streak	5 minutes

• Cache key: userId:route:params
• Use lru-cache npm package (zero infra) or Supabase api_cache table with expires_at column
• Expose a ?refresh=true query param to force-bust cache for a route
• Add X-Cache: HIT | MISS header on API responses for debuggability

Acceptance Criteria

• Cache layer implemented in src/lib/cache.ts
• All 4 metric API routes use the cache
• TTL is configurable via constants (not hardcoded magic numbers)
• ?refresh=true param bypasses cache and resets it
• Dashboard shows a "Refreshed X minutes ago" timestamp per widget
• No additional paid infrastructure required (in-memory or Supabase-only)
• Existing type-check and lint pass (npm run lint && npm run type-check)

I would like to work on this under GSSoC

[IshitaSingh0822]

I would like to work on this under GSSoC
/assign

[github-actions]

Assigned to @IshitaSingh0822! You have 7 days to open a PR. No PR after 7 days = auto-unassigned so others can pick it up. Good luck!