MyTechDailyNews Software Guide: From 2,500 requests to 24, How GitHub Rebuilt Star History Without Exposing Stargazers

For MyTechDailyNews Software readers who follow daily tool updates, the lesson is practical: an API path that once required 2,500 requests became 24 once GitHub moved from person lists to time-windowed aggregate counts. The endpoint still answers the question maintainers actually asked - how did star counts move after a release or launch? - while returning up to 30 weeks of daily star counts in one request and no stargazer identities.

Checklist: what software teams should know before rewriting star-history charts

• Identify every use case that only needs a trend curve; if it does not need usernames, avoid GitHub API stargazer list pagination.
• Assume access is narrower than before: stargazer and watcher data are restricted to repository administrators and collaborators.
• Handle empty responses and 403 Forbidden paths explicitly in dashboards and CI checks.
• Plan pagination around weeks, not people: one response can cover up to 30 weeks.
• Re-estimate rate-limit budgets using the new numbers, especially for large repositories such as react/react.

The user problem behind the rebuild

Project watchers and maintainers use star history as an approximate signal of interest. They compare activity around releases, launches, announcements, or other events. The question is whether the curve changed, not who created each star. Under the old GitHub API response, identity appeared to be part of the contract because each timestamp arrived attached to a user. Once that coupling was removed, the system could focus on dates and counts instead of usernames, which is what Star History and similar tools needed.

Old endpoint: list of people first, history second

The original GET /repos/{owner}/{repo}/stargazers endpoint was designed to answer who starred a repository. Its result was a paginated list of people. If a request used a custom media type, the rows also carried starred_at timestamps. The data model recorded the current star set: a removed star deletes the record. That makes a live star count simple, but it was not a historical event log.

Because each page held at most 100 people, tools reconstructing a full curve needed many requests, proportional to popularity. For react/react, about 251,000 stars meant about 2,511 requests. That forced rate-limit errors, sampling shortcuts, or slow chart generation.

Database cost: why privacy alone did not fix performance

Returning counts instead of identities removed an abuse path, but it did not automatically make the query cheap. A pagination bug made each request count all current stars to infer the number of pages, even when the caller received one page. In the week before we restricted access, nearly 37,000 of those count queries were logged as slow, averaging nearly 3 seconds; database safeguards killed more than 1,000, and timeouts followed.

After we restricted access, the database served about 60% fewer stargazer requests, and total time spent on the count query fell by about 80%.

Approaches: small response, huge query, or week-filtered aggregation

Design path	Intended user value	Blocking issue	What it taught
Keep per-star rows, hide identity	Preserve starred_at while closing identity harvesting	Clients still had to paginate many thousands of rows to produce aggregate history	A privacy patch can leave the old pagination mismatch intact
Group all stars, then paginate buckets	Return daily or weekly buckets in smaller pages	Database had to find, group, and sort all repository stars before LIMIT and OFFSET; react/react could inspect roughly 6 million rows across the full reconstruction	Response size and query cost are different things
Filter by calendar week before grouping	Match the actual job: inspect trends over weeks or around known events	Exceptionally dense weeks can still be expensive; calendar boundaries and removed stars remain tradeoffs	Predicate before aggregation, then return daily counts for that week range

Shipped path: paginate weeks, then group daily counts

The shipped design translates page and per_page into an indexed created_at range. It filters the repository's stars to the requested calendar weeks, then groups matching records into daily counts. A response covers up to 30 weeks; moving backward through history is handled by advancing pages.

This changes the work order. The database no longer scans every current star for each page. For react/react, the full history takes about 24 requests instead of about 2,511 requests, while processing roughly 251,000 rows across the entire read. The result also uses the same shape as the weekly commit activity endpoint, GET /repos/{owner}/{repo}/stats/commit_activity, which makes adoption easier for repository analytics tools.

Migration steps for developers and IT support

1. Separate analytics calls from identity-dependent features. If a UI shows a star count graph, do not keep stargazer usernames as a hidden dependency.
2. Audit permission states. If the integration lacks repository administrator or collaborator access, expect an empty response or 403 Forbidden and design a visible fallback.
3. Call the aggregate weekly endpoint in page order, reading up to 30 weeks per request until the chart reaches the needed history.
4. Stop paging early when the event window is covered, to avoid rate limits while still showing enough context.
5. Document the metric as approximate interest, noting that removed stars and unusual weekly volume can distort comparisons.

Privacy, permission, and compatibility notes

Bulk collection of public stargazer lists had enabled spam or phishing abuse. The new endpoint reduces that risk by returning counts rather than identities. The compatibility caveat is that any code that previously extracted usernames from the old response cannot keep doing so without collaborator permission. If a product only needs a timeline, the aggregate endpoint is the safer and cheaper path; if it truly needs people, it should surface why that access is required and respect the restricted list behavior.

Community feedback and the purpose-built endpoint

The disruption was not only a technical failure: it also revealed the real contract. Tianzhou Chen, star-history.com maintainer and Bytebase co-founder, described how the change initially disturbed Star History users, then became a collaboration after GitHub’s Community team connected the project with product engineering. The outcome was a purpose-built endpoint for counts over time. Feedback can still be shared through GitHub Community.

Extra database cleanup on GitHub.com

While comparing old and new performance, engineers found the same on-demand counting pattern behind the repository stargazers page on GitHub.com. That page was updated to use the repository's cached star count. Slow queries from the page, which had numbered in the hundreds each week, dropped to zero. A similar fix was shipped to other stargazer API endpoints.

Common misconceptions

• Smaller JSON equals smaller work: false, because LIMIT and OFFSET can run after grouping and sorting.
• Star history must include identities: false, maintainers needed counts and dates, not usernames.
• One endpoint removes all scaling risk: false, unusually dense weeks still need care.

Data points to cite

• The headline number: 2,500 requests became 24 in the rebuilt path.
• Permission status: lists are restricted to repository administrators and collaborators; unauthorized callers may get empty or 403 Forbidden.
• Scale: react/react with about 251,000 stars used about 2,511 requests, now about 24 requests.
• Database before: In the week before we restricted access, nearly 37,000 count queries averaged nearly 3 seconds; more than 1,000 were killed.
• Database after: After we restricted access, the database served about 60% fewer stargazer requests, and count-query time fell by about 80%.

FAQ

Can the new API still show a full growth curve?

Yes, if a caller is willing to page backward through weeks. For react/react, that means about 24 requests rather than about 2,511 requests.

Why did the old method need so many pages?

Because each stargazer page held at most 100 people, and the endpoint returned current stars, not a precomputed trend.

Is the weekly shape tied to repository events?

The endpoint returns daily counts within up to 30 weeks; maintainers usually use it around releases, launches, or announcements.

Where can users ask for refinements?

Through GitHub Community.

Action recommendations

For daily software readers and integration owners, the takeaway is not that privacy was added instead of performance. GitHub improved both by asking what the workflow needed: counts over time, week boundaries, cached totals where lists were unnecessary. Teams building analytics should copy that pattern - narrow the row set before aggregation, remove identity unless the user actually needs it, and document the limits that remain.

MyTechDailyNews Software will keep tracking how API contracts change when developer tools, permissions, and database economics move in opposite directions.