Is your feature request related to a problem? Please describe.
To prevent hitting GitHub GraphQL rate limits, CommitPulse caches contribution data. However, if a user makes a new commit and wants to see it immediately on their profile README, they currently have to wait for the 5-minute cache freshness window to expire.
Additionally, developers cannot currently see whether their request served from cache or hit the backend live API, which makes debugging API performance difficult.
Describe the solution you'd like
Introduce a way to bypass the cache via a query parameter (e.g., &refresh=true) and include cache performance details in the API response headers.
- Bypass Query Parameter: Check for a parameter like
refresh=true or bypassCache=true. When present, the API should bypass the Redis/memory cache, fetch fresh data directly from the GitHub GraphQL API, and update the cache store.
- Cache Headers: Return a custom response header:
X-Cache-Status: HIT (if served from the cache)X-Cache-Status: MISS (if fetched fresh from the GitHub API)
- Rate Limiting: Implement simple throttling on the
refresh=true parameter (e.g., maximum 1 force-refresh per user every 30 seconds) to prevent abuse or DDoS attacks on GitHub's GraphQL endpoints.
Describe alternatives you've considered
- No cache bypass: Users are forced to wait for automatic cache expiration, resulting in poor user experience when testing new commits.
- Lower cache duration globally: Reduces caching efficiency and increases the risk of exhausting GitHub API rate limits.
Is your feature request related to a problem? Please describe.
To prevent hitting GitHub GraphQL rate limits, CommitPulse caches contribution data. However, if a user makes a new commit and wants to see it immediately on their profile README, they currently have to wait for the 5-minute cache freshness window to expire.
Additionally, developers cannot currently see whether their request served from cache or hit the backend live API, which makes debugging API performance difficult.
Describe the solution you'd like
Introduce a way to bypass the cache via a query parameter (e.g.,
&refresh=true) and include cache performance details in the API response headers.refresh=trueorbypassCache=true. When present, the API should bypass the Redis/memory cache, fetch fresh data directly from the GitHub GraphQL API, and update the cache store.X-Cache-Status: HIT(if served from the cache)X-Cache-Status: MISS(if fetched fresh from the GitHub API)refresh=trueparameter (e.g., maximum 1 force-refresh per user every 30 seconds) to prevent abuse or DDoS attacks on GitHub's GraphQL endpoints.Describe alternatives you've considered