GitHubs stjernehistorik: 2.511 API-kald bliver til 24

GitHub viste i sin tekniske gennemgang fra 14. oktober 2026, hvordan en fuld stjernehistorik for react/react kan hentes med cirka 24 API-kald mod tidligere cirka 2.511. Det allerede lancerede endpoint returnerer daglige stjerneantal samlet i op til 30 kalenderuger pr. svar, uden navne eller profiler på dem, der har givet stjerner. For en udvikler, der bygger en historisk kurve, ændres både datakilden og arbejdet med at samle punkterne.

Gennemgangen handler om et endpoint, som Star History allerede havde taget i brug. Vedligeholder Tianzhou Chen forklarede i projektets beretning fra 5. september 2026, at den gamle metode stødte på en grænse ved 400 sider og 40.000 stjerner; om de nye kurver skrev han: “The chart is back.” For klienter, der stadig henter individuelle stjernegivere, kræver skiftet en ændring af både forespørgslen og måden, kurven beregnes på.

Fra personlister til ugeblokke

Den gamle rute, GET /repos/{owner}/{repo}/stargazers, viser de personer, der aktuelt har stjernemarkeret et repository. Med svarformatet application/vnd.github.star+json følger tidspunktet for hver stjerne med. Et kurveværktøj måtte hente siderne med personer, udtrække tidspunkterne og sortere dem, før det kunne tælle stjerner pr. dag. For et stort repository steg antallet af forespørgsler derfor med antallet af nuværende stjerner.

Den nye rute, GET /repos/{owner}/{repo}/stargazers/history, leverer optalte værdier for kalenderuger. Den svarer direkte på kurveværktøjets spørgsmål: Hvor mange af de nuværende stjerner blev oprettet på hver dag? Brugernavne, avatarer og profillinks er ikke med i dette svar. Forskellen har praktisk betydning, fordi adgangen til listerne over stjernegivere blev begrænset til repositoryets administratorer og samarbejdspartnere efter misbrug til spam og phishing.

Før: Hent personposter side for side, behold tidsstemplerne, kassér identiteterne, og beregn daglige antal.
Nu: Hent ugeposter med daglige antal, sæt siderne sammen, og beregn den kumulative kurve.

Privatlivsgevinsten ligger i selve svarformatet. Et offentligt værktøj kan vise ændringer i interessen for et projekt uden at modtage data om de enkelte personer bag stjernerne. Tidsserien kan stadig bruges til at se, om en udgivelse eller annoncering falder sammen med en ændring i antallet af stjerner.

Endpoint, sider og svarformat

GitHubs REST-dokumentation angiver, at GET /repos/{owner}/{repo}/stargazers/history kan bruges uden godkendelse til offentlige ressourcer, og at per_page højst er 30 uger, mens page højst er 100. Et kort eksempel er GET /repos/react/react/stargazers/history?per_page=30&page=1. Første side indeholder de nyeste uger; højere sidetal går bagud mod repositoryets oprettelse.

Hver ugepost har felterne week, total og days. Week er et Unix-tidsstempel for ugens begyndelse, total er antallet af stjerner for den pågældende uge, og days er de daglige antal med søndag først. En uge uden stjerner er repræsenteret med nulværdier, så en klient kan sammenkæde siderne uden at opfinde manglende perioder. Uge- og dagsgrænserne er dog ikke garanteret at ligge på UTC; det kan forskyde sammenligningen med begivenheder, hvis en anden tidszone bruges til grafens akse.

Migrationen ændrer den lokale datamodel. Hvor den gamle integration lagrede eller gennemløb poster med en person og et tidspunkt, kan den nye arbejde med ugeposter og deres dagstal. Klienten skal bevare datoordenen på tværs af sider og hente den del af historikken, som kurven skal dække. Funktioner, der viser navnene på stjernegivere, kan ikke læse dem ud af historiksvaret; de kræver en anden datakilde og de relevante adgangsrettigheder.

Ugens total skal summeres til en kurve

Feltet total er en uges antal, ikke repositoryets samlede stjerneantal ved ugens slutning. For at tegne en kurve med det akkumulerede antal skal klienten vende de nyeste-først-sider til kronologisk orden og derefter lægge dagstallene sammen løbende. Hvis tre på hinanden følgende dage eksempelvis har ændringerne 2, 3 og 1, bliver punkterne på en kumulativ kurve 2, 5 og 6. Ugessummen kan bruges til at kontrollere, at dagstallene for den samme uge er læst samlet.

Her ligger begrænsningen ved migrationen: Et nyere sideudsnit giver periodens ændringer, men ikke niveauet ved periodens start. For en kurve fra repositoryets oprettelse må klienten hente samtlige uger og summere fremad. Skal den kun vise en sammenhængende nyere periode, kan det aktuelle antal fra GET /repos/{owner}/{repo}/stargazers/count bruges som anker; ved at trække de efterfølgende dagstal fra kan klienten beregne startniveauet. Isolerede ugeposter uden et kendt niveau giver ikke den samme mulighed.

Historikken bygger desuden på de stjerner, som stadig findes. Når en bruger fjerner sin stjerne, forsvinder posten fra den underliggende liste; endpointet er derfor ikke en hændelseslog over alle tidligere tilføjelser og fjernelser. En kurve, der genberegnes senere, kan af den grund ændre sig bagud i tid. Det er en væsentlig forskel, hvis kurven bruges som dokumentation for interessen på en bestemt historisk dato.

Hvorfor databasen slipper lettere

Færre felter i et JSON-svar ville ikke alene have løst databaseproblemet. Hvis databasen først fandt alle repositoryets stjerner, grupperede dem efter dag og dernæst valgte den efterspurgte side, ville hver ny side stadig kræve en optælling af hele mængden. Den gamle paginering talte desuden alle aktuelle stjerner ved hver sideforespørgsel på grund af en fejl. I den nye løsning omsættes page og per_page først til et indekseret tidsinterval, så kun stjerner inden for intervallet bliver grupperet og talt.

Dermed består en fuld historik af forskellige tidsudsnit frem for gentagne optællinger af de samme poster. Besparelsen i databasearbejde skyldes rækkefølgen af filtrering og optælling; færre API-kald alene ville ikke have været nok. Et særligt tæt tidsinterval kan stadig være dyrt, fordi ugefilteret begrænser perioden, men ikke antallet af stjerner i den.

Læs også: