GitHub reemplaza el scraping de stargazer por una API de historial seguro para la privacidad

GitHub dijo que ha sustituido una solución basada en stargazer por un endpoint de historial diseñado específicamente para ello que devuelve tendencias agregadas de estrellas sin exponer identidades individuales. El cambio importa porque los mantenedores usan el historial de estrellas para evaluar si una versión, lanzamiento o evento cambió la trayectoria de un proyecto, mientras que GitHub afirmó que el enfoque antiguo estaba siendo abusado para la recopilación de datos y además era caro de atender.

Qué cambió GitHub

En una publicación de ingeniería del 14 de octubre de 2026 , GitHub dijo que la nueva API de historial de estrellas del repositorio puede devolver hasta 30 semanas de conteos diarios de estrellas en una sola solicitud, sin identificar identidades. GitHub dijo que el endpoint filtra las estrellas por tiempo antes de contarlas, en lugar de contar primero y recortar la respuesta después, lo que, según dijo, reduce el trabajo de base de datos.

La empresa dijo que el anterior endpoint GET /repos/{owner}/{repo}/stargazers estaba diseñado para listar a stargazers actuales, no para actuar como un registro histórico de eventos. Como las estrellas se eliminan cuando los usuarios desestrellan un repositorio, el modelo no conserva un historial completo de la actividad pasada de estrellas y desestrellas. GitHub dijo que las herramientas habían estado leyendo páginas de registros de stargazer y descartando los nombres de usuario para reconstruir una curva solo a partir de las marcas de tiempo.

Por qué el enfoque antiguo se convirtió en un problema

GitHub dijo que el endpoint original generó dos problemas. Primero, había identidades disponibles para la recopilación masiva, lo que según él llevó a actores malintencionados a extraer listas públicas de Stargazer para campañas de spam y phishing. Segundo, los repositorios con muchas estrellas podían obligar a la base de datos a procesar miles de entradas para devolver una sola página.

Para react/react, que según GitHub tenía unas 251,000 estrellas, reconstruir la curva completa requería unas 2,511 solicitudes bajo el enfoque antiguo. GitHub también señaló que un error de paginación hacía que cada solicitud contara todas las estrellas para determinar el número de páginas, incluso cuando solo se devolvían hasta 100 personas. En la semana anterior a la restricción del acceso, GitHub informó que se registraron casi 37,000 consultas de conteo lento, con una media de casi 3 segundos cada una, y que las salvaguardas de bases de datos eliminaron más de 1,000 de ellas. Tras restringir el acceso, GitHub dijo que las solicitudes de Stargazer cayeron aproximadamente 60% y el tiempo total dedicado a la consulta de recuento cayó en unos 80%.

Cómo funciona el nuevo endpoint

GitHub dijo que evaluó varios diseños antes de decidirse por un enfoque de intervalo temporal. Una opción habría devuelto las marcas de tiempo de Stargazer sin identidades, pero GitHub dijo que eso aún requeriría que los consumidores de la API pasaran por un gran número de registros individuales. Otra opción habría agregado primero las estrellas y paginado después, pero GitHub dijo que un plan SQL estándar seguiría escaneando y agrupando todas las filas coincidentes antes de aplicar LIMIT y OFFSET.

El diseño enviado en cambio mapea página y per_page a un rango de created_at indexado, filtra las estrellas primero a ese rango y luego agrupa los resultados en conteos diarios. GitHub dijo que eso significa que uno solicitud puede cubrir hasta 30 semanas de historial, y que la página creciente retrocede a lo largo del historial de un repositorio. En el ejemplo de react/react, GitHub dijo que el nuevo enfoque requiere unas 24 solicitudes en lugar de unas 2,511, mientras examina cada estrella aproximadamente una vez a lo largo del historial completo.

Límites y compensaciones restantes

GitHub dijo que el nuevo endpoint es más seguro y predecible, pero no está libre de restricciones. Los límites del calendario afectan cómo se divide el historial, las estrellas eliminadas no se conservan en el modelo y semanas inusualmente densas pueden seguir produciendo consultas lentas o costosas. GitHub también dijo que las semanas densas siguen siendo una limitación de escalado aunque la ruta normal de petición ya no consulta a todas las estrellas actuales.

La empresa dijo que su revisión del problema del historial de estrellas también llevó a una corrección separada en GitHub.com, donde la página del repositorio stargazers se actualizó para usar conteos de estrellas en caché en lugar de contar estrellas bajo demanda. GitHub dijo que ese cambio eliminó cientos de consultas lentas cada semana de esa página.