The reading room · Digna Legi
From 2,500 requests to 24: Rebuilding star history without the stargazers
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. Performance figures are reported in the supplied article text and are not independently verified; referenced charts are not provided.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 2 min with detail
Why read this
Smaller API responses can leave database costs unchanged: GitHub made star history cheaper by filtering records before counting them.
AI brief · Checked against source text
The main idea
GitHub’s star-history redesign separates the information maintainers need—daily counts—from the identities its old interface exposed, while moving time filtering ahead of database aggregation. Removing usernames addressed identity harvesting, but neither anonymous records nor smaller grouped responses solved the processing cost: the database needed to restrict which stars it examined before calculating counts.
Some background helpful. Basic familiarity with APIs, database queries, pagination, and indexes.
Go a little deeper
An inherited interface can disguise the requirement
Every timestamp previously arrived attached to a person, making identity appear necessary for historical analysis. Conversations with maintainers established that they wanted an approximate interest curve around launches and releases. That distinction opened a different interface design. The initial access restriction also disrupted legitimate tools, showing why identifying the underlying job mattered alongside closing the scraping route.
Current records are not historical events
The underlying star model stores current supporters and deletes a record when someone removes a star. Consequently, a curve reconstructed from these records represents when surviving stars were created, rather than a complete record of additions and removals. The new endpoint changes access and processing efficiency; its counts still need to be interpreted within that storage model.
Pagination must constrain the expensive work
In the rejected grouped-query design, the database grouped and sorted all matching stars before applying the page limit. A small page therefore concealed substantial repeated work. The shipped design instead converts page settings into an indexed creation-date range, then groups only matching records into daily counts. The important distinction is where the page boundary takes effect in the execution sequence.
A case from the article
A popular repository exposes repeated work
For react/react, roughly 251,000 stars required about 2,511 requests through the old list interface. Merely grouping results would reduce that to 24 requests but still examine roughly six million rows because each request would reprocess the full star set. Time filtering retained the 24-request total while examining each star about once across the full history, separating client savings from database savings.
How the case is made
The account combines maintainer feedback, database query logs, rejected implementation approaches, and reported before-and-after request and row counts.
Where the idea has limits
Calendar windows bound time, not workload: an exceptionally dense week can still produce an expensive query.
A question to take away · from Digna Legi
Where does an interface expose information simply because it shares a storage record with the information people actually need?
What the original adds
The source also describes aligning the response with weekly commit activity and replacing on-demand counts on the repository stargazers page with a cached count, reducing that page’s logged slow queries to zero.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.