[FEAT] Add Upstash Redis caching layer for GitHub API responses

[Priyanshu-byte-coder]

Summary

Every dashboard load fires multiple GitHub API calls. With the 5000 req/hr rate limit shared across all routes, heavy users and repeated refreshes can hit the limit quickly. Redis caching would drastically reduce API calls.

Expected Behaviour

• First request hits GitHub API and caches response in Redis with TTL
• Subsequent requests within TTL return cached data instantly
• TTL per endpoint: contributions (5min), repos (10min), PRs (10min), streak (2min)
• Cache key: {userId}:{endpoint}:{params}
• Cache invalidation: user-triggered sync bypasses cache and refreshes it

Implementation Notes

• Use @upstash/redis and @upstash/ratelimit packages
• Add UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN to .env
• Create a cache wrapper: cacheGet/cacheSet utilities in lib/cache.ts
• Each /api/metrics route uses the cache wrapper before calling GitHub API

GSSoC Info

• Difficulty: Advanced — 55 pts
• Area: Performance / Infrastructure

[maria-453]

Hi @Priyanshu-byte-coder , I’d like to work on this issue under GSSOC26.

This seems like a great backend/performance optimization task, and I’d love to contribute to it.

My plan is to:

• Integrate Upstash Redis for caching GitHub API responses
• Create reusable cacheGet / cacheSet utilities in lib/cache.ts
• Implement endpoint-specific TTL strategies for contributions, repos, PRs, and streak metrics
• Add cache bypass + refresh logic for manual sync actions
• Ensure cache keys are structured properly using {userId}:{endpoint}:{params}
• Update .env.example and document the Redis setup clearly

This should help reduce repeated GitHub API calls significantly and improve dashboard response times while avoiding rate-limit issues.

Please assign this issue to me if it’s available. Thanks!

[saurabhhhcodes]

Hi @Priyanshu-byte-coder, I would like to work on this under GSSoC26.

I can add this as a reusable Redis-backed cache layer around the metrics/GitHub API flow, with endpoint-specific TTLs, deterministic keys using user + endpoint + params, and explicit bypass/refresh support for user-triggered syncs so stale data does not get stuck. I will also keep the implementation graceful when Upstash env vars are absent, so local development still works without Redis.

Please assign this to me if it is available.

[saurabhhhcodes]

Raised PR #311 for this: #311

Implementation includes a graceful Upstash Redis cache helper, endpoint-specific TTLs for contributions/repos/PRs/streak, deterministic user/account-scoped keys, and explicit bypass support via refresh=1, bypassCache=true, sync=true, or x-devtrack-cache-bypass: 1.

Validation and the local build note are included in the PR description. If accepted for GSSoC, please add the scoring labels (gssoc:approved, level:advanced, quality:clean, type:performance, and type:backend).