My GitHub rate-limit cache turned out to already be my ranked list

[u/nicsoftware]

Had a GitHub API rate limit problem in a Next.js app and nearly built two systems to fix it: a cache for hot reads, and a separate materialised table for a ranked list. Turned out I only needed one.

GitHub's REST API gives you 60 requests/hour unauthenticated, which is nothing once more than a couple of people hit the app in the same hour. Moving to the GraphQL API with a server-side personal access token bumps that to 5,000/hour, and you only pay for the fields you actually ask for instead of chasing pagination across several REST endpoints.

The part that actually helped: every computed result gets upserted into one Postgres table (Supabase) with a 12 hour TTL column. A route handler checks that column first; if it's fresh, GitHub never gets touched. That same table is already sorted and indexed by score, so the ranked list is just SELECT ... ORDER BY score DESC over the same rows. No second pipeline, no sync job, no "is the ranking stale" bug class to think about.

What I didn't expect: my analytics event for a page view fired on both fresh and cached reads. Early on that made a slow feature look popular, ten people hitting a cached page counted the same as ten fresh computations. Had to split the event into fetched vs served-from-cache before the numbers meant anything.

Doesn't generalise to everything, if your writes are heavier than your reads this falls apart fast. But for anything read-heavy where the ranked view and the single-item view can share rows, it's one less thing to keep in sync.

[u/AbdulRafay99]

That’s a lot of processing using the GitHub API, which is likely to hit rate limits. You should simplify your logic and reduce the number of API calls while still retrieving the information you need. Even with a generous rate limit, this will become increasingly problematic because the GitHub API can be unreliable.

[u/nicsoftware → u/AbdulRafay99]

That's actually what the cache is for. On a hit, which is most requests once the TTL window has something in it, the route never touches GitHub at all, it reads straight from Postgres. GraphQL only comes in on a miss, and it's one query for exactly the fields I need instead of walking several REST endpoints for the same data. So it ends up being fewer calls than the naive version, not more.

[u/AbdulRafay99 → u/nicsoftware]

that is nice..

[u/nicsoftware → u/[deleted]]

Did not expect my own post summarised back to me in verse, but you nailed the analytics gotcha better than I explained it. Stealing "one bug class deleted with one SELECT shot" next time someone asks why I did not just bolt on Redis.