Raccogli dati da GitHub oltre il limite di velocità dell'API: stelle, dipendenti
L'API di GitHub limita le chiamate non autenticate a 60 all'ora e nasconde completamente dipendenti e tendenze. Ecco come estrarre i segnali che contano attraverso IP economici.
GitHub è una miniera d'oro per la ricerca - curve di adozione, slancio dei concorrenti, grafici di dipendenza, segnali di assunzione - e la sua API ufficiale ti fornirà una parte di tutto ciò gratuitamente. Poi si ferma. Le chiamate non autenticate sono limitate a 60 all'ora, e i due dataset più richiesti, il grafico dei dipendenti e la pagina delle tendenze, non sono affatto nell'API. Questa guida copre come raccogliere dati da GitHub oltre questi limiti: cosa ti offre l'API, cosa devi leggere dall'HTML e perché GitHub è un obiettivo raro dove i proxy economici di datacenter e IPv6 sono lo strumento giusto.
Conosci i limiti prima di affrontarli
Inizia con l'API - è strutturata, benedetta e conveniente in termini di quota se ti autentichi. I numeri che modellano tutto: le richieste REST non autenticate sono limitate a 60 all'ora, conteggiate per IP; un token autenticato ottiene 5.000 all'ora; l'API di ricerca è ancora più stretta a 30 richieste al minuto autenticate (10 non autenticate). Il dettaglio chiave è che il limite non autenticato è conteggiato per IP - ed è proprio per questo che instradare le letture su molti IP moltiplica il tuo margine.
import requests
# Authenticated API call - watch the rate-limit headers
headers = {"Authorization": "Bearer YOUR_GH_TOKEN",
"Accept": "application/vnd.github+json"}
r = requests.get("https://api.github.com/repos/psf/requests", headers=headers, timeout=15)
repo = r.json()
print(repo["stargazers_count"], repo["forks_count"], repo["open_issues_count"])
print("remaining this hour:", r.headers["X-RateLimit-Remaining"])Usa l'API per tutto ciò che espone chiaramente, e usa git clone per i contenuti dei file - clonare e processare un repository localmente è più veloce e più delicato rispetto a raccogliere singole pagine di file. La raccolta di HTML è per i segnali che l'API limita in modo inutile o omette completamente.
Cosa devi leggere dall'HTML
Tre dataset di alto valore vivono solo sulle pagine renderizzate. Il grafico dei dipendenti - il conteggio "Usato da" di GitHub e l'elenco dei repository che dipendono da un pacchetto - è uno dei più forti metriche di adozione che ci siano, e non è nell'API. Le pagine di tendenza (github.com/trending, filtrabili per lingua e finestra) sono solo HTML. E le pagine di argomento mostrano repository per soggetto in modo molto più utile di quanto consenta la quota di ricerca. Tutti e tre sono HTML server-renderizzati semplici, quindi una semplice richiesta e analisi funziona - non è necessario un browser.
import requests
from bs4 import BeautifulSoup
# Scrape the trending page through a datacenter proxy
PROXY = "http://USER:PASS@dc.quantumproxies.io:8000"
def trending(language="python", since="daily"):
url = f"https://github.com/trending/{language}?since={since}"
r = requests.get(url, proxies={"https": PROXY}, timeout=20,
headers={"User-Agent": "Mozilla/5.0"})
soup = BeautifulSoup(r.text, "html.parser")
repos = []
for row in soup.select("article.Box-row"):
name = row.select_one("h2 a")["href"].strip("/")
stars = row.select_one("a[href$='/stargazers']")
repos.append({"repo": name,
"stars": stars.get_text(strip=True) if stars else None})
return repos
print(trending("rust", "weekly")[:5])
GitHub è un obiettivo di datacenter (e forse IPv6)
Ecco la parte che le persone sovraingegnerizzano. Le pagine pubbliche di GitHub sono server-renderizzate, indulgenti e non presentano sfide aggressive di JavaScript - quindi non hai bisogno di IP residenziali premium per leggerle. Questo è un caso da manuale per proxy di datacenter: economici, veloci e abbondanti, distribuiti in modo che nessun singolo IP si avvicini al limite non autenticato o attivi un limite di velocità secondario. Optare per i residenziali qui significa pagare prezzi di lusso per un lavoro che un IP economico svolge perfettamente. La nostra guida su quando i proxy di datacenter sono la scelta giusta illustra esattamente questo tipo di obiettivo indulgente e ad alto throughput.
C'è un'opzione ancora più economica che vale la pena testare: IPv6. Quando un obiettivo risponde su IPv6, i pool di proxy IPv6 ti offrono uno spazio di indirizzi enorme e a basso costo - ideale per diffondere letture limitate per IP su migliaia di uscite. GitHub sta implementando il supporto IPv6, quindi è uno dei pochi grandi obiettivi in cui vale la pena verificare piuttosto che assumere. Testalo prima di impegnarti: esegui l'obiettivo attraverso il nostro controllo di compatibilità IPv6 gratuito, e leggi l'economia nella nostra guida completa ai proxy IPv6.
Ottieni proxy di datacenter veloci per GitHub
Attenzione al limite di velocità secondario
I limiti orari non sono l'unico limite che incontrerai. GitHub esegue anche un rilevamento degli abusi che reagisce a traffico esplosivo, altamente concorrente o sospettosamente regolare - quindi anche se ti trovi comodamente sotto il limite numerico, martellare da un singolo IP può causare un blocco temporaneo. Le difese sono le stesse che ti rendono un cliente educato: limita la concorrenza, aggiungi un po' di jitter tra le richieste, rispetta qualsiasi intestazione Retry-After che il server ti fornisce, e distribuisci il carico in modo che nessuna uscita singola porti mai un modello incontrollato. Questo è il vero motivo per cui un pool ampio è importante - non è solo l'aritmetica dei 60 all'ora, è che nessun IP individuale dovrebbe mai sembrare uno script fuori controllo. Ritirati al primo 403 o rallentamento piuttosto che riprovare direttamente in un divieto più lungo.
Trasformare i dati dei repository in informazioni sugli strumenti di sviluppo
Il punto di tutto ciò è il livello di analisi. Traccia la velocità delle stelle di una libreria concorrente e il conteggio dei dipendenti nel tempo e stai osservando l'adozione in tempo reale. Confronta le pagine di tendenza per lingua settimana dopo settimana per individuare strumenti in ascesa prima che siano evidenti. Estrai elenchi di contributori per leggere la dimensione del team e i segnali di assunzione. Combina le suddivisioni linguistiche su un argomento per mappare un intero ecosistema. Cattura istantanee dei repository su un programma, memorizza ogni cattura con un timestamp e i delta diventano il prodotto - slancio, non un singolo numero. Una lettura una tantum di 40.000 stelle è una curiosità; lo stesso repository che aggiunge 2.000 stelle a settimana mentre il conteggio dei suoi dipendenti sale è un vero segnale di adozione su cui puoi agire prima che il mercato più ampio se ne accorga.
import requests
from bs4 import BeautifulSoup
# The 'Used by' dependents count - a top adoption signal, HTML-only
def used_by(owner, repo):
url = f"https://github.com/{owner}/{repo}/network/dependents"
proxy = "http://USER:PASS@dc.quantumproxies.io:8000"
r = requests.get(url, proxies={"https": proxy}, timeout=20,
headers={"User-Agent": "Mozilla/5.0"})
soup = BeautifulSoup(r.text, "html.parser")
tab = soup.select_one("a.btn-link.selected")
return tab.get_text(strip=True) if tab else None
print(used_by("pallets", "flask")) # e.g. '1.4m Repositories'Un'abitudine mantiene i costi ragionevoli su larga scala: richiedi solo ciò di cui hai bisogno. Le pagine dei repository sono leggere, ma se ti espandi a migliaia di repository, blocca le risorse e riutilizza le connessioni - le nostre note su ridurre i costi di larghezza di banda dei proxy si applicano anche a un obiettivo economico, perché il guadagno si moltiplica.
Domande frequenti
Qual è il limite di velocità dell'API di GitHub?
Le richieste REST non autenticate sono limitate a 60 all'ora, conteggiate per indirizzo IP. Un token autenticato aumenta questo limite a 5.000 all'ora. L'API di ricerca è separata e più stretta - 30 richieste al minuto autenticate, 10 non autenticate. Poiché il limite non autenticato è per IP, diffondere le letture su un pool di proxy è un modo efficace per scalare la raccolta.
Posso raccogliere dati da GitHub che l'API non espone?
Sì. Il grafico dei dipendenti ("Usato da"), le pagine di tendenza, gli elenchi di argomenti e le timeline degli stargazer sono solo HTML o fortemente limitati tramite l'API. Sono pagine server-renderizzate semplici, quindi una richiesta e analisi con BeautifulSoup funziona senza un browser. Instrada attraverso proxy di datacenter e diffondi le letture per rimanere sotto i limiti di velocità secondari.
Ho bisogno di proxy residenziali per GitHub?
Di solito no. Le pagine pubbliche di GitHub sono indulgenti e server-renderizzate senza sfide aggressive di JavaScript, quindi i proxy di datacenter economici le gestiscono bene - l'obiettivo è diffondere le richieste su IP, non mascherarle come famiglie. Se l'obiettivo risponde su IPv6, i pool IPv6 sono ancora più economici. Riserva gli IP residenziali per obiettivi veramente ostili.
Dovrei usare git clone o raccogliere pagine di file?
Clona per i contenuti dei file. Eseguire git clone e processare il repository localmente è più veloce, più delicato su GitHub e evita completamente i limiti di velocità per file. Riserva la raccolta HTML e l'API per i metadati e i segnali - stelle, dipendenti, tendenze, contributori - che non puoi ottenere dai file controllati.
GitHub premia un approccio stratificato: API dove è generosa, git clone per i file e raccolta HTML per i segnali di adozione che nasconde - tutto distribuito su IP economici in modo che nessun singolo indirizzo raggiunga il muro dei 60 all'ora. Testa per IPv6, affidati ai pool di datacenter e l'intera piattaforma diventa un dataset di ecosistema di sviluppo live.