GitHub'ın yeni star history API'si 2.511 isteği 24'e indiriyor ve stargazer kimliklerini kaldırıyor

Ne oldu

GitHub, araçların bir depoun star history'sini grafiklediği yöntemi değiştirdi; popüler bir proje için gereken API çağrısı sayısını binlerden kabaca iki düzineye indirirken yanıttan kullanıcı kimliklerini tamamen kaldırdı. GitHub Blog'a göre yeni star history endpoint'i tek bir istekte 30 haftaya kadar günlük star sayısını döndürüyor ve yaklaşık 251.000 star'a sahip react/react deposu için eksiksiz eğriyi oluşturmak artık eski akımın gerektirdiği 2.511 yerine yaklaşık 24 istek sürüyor.

Stargazer listeleri neden bir yük haline geldi

Maintainer'lar bir lansmanın, sürümün ya da duyurunun bir projenin seyrini değiştirip değiştirmediğini değerlendirmek için star history'yi kullanıyor. Eski API üzerinden bu eğriyi yeniden oluşturmak için bir aracın, o an bir depoyu star'layan herkesin listesini sayfa sayfa gezmesi, timestamp'leri saklaması ve kullanıcı adlarını atması gerekiyordu. Eski GET /repos/{owner}/{repo}/stargazers endpoint'i sayfa başına en fazla 100 kişi döndürüyordu ve custom media type istendiğinde bir starred-at timestamp'i ekleniyordu; dolayısıyla iş, deponun popülerliğiyle ölçekleniyordu.

GitHub Blog'un açıkladığına göre bu tasarım iki cephede sorun yaratıyordu. Herkese açık kimlikler ve timestamp'ler, listeleri spam ve phishing kampanyaları yürüten scraper'lar için hedef haline getiriyordu. Bu arada sayfalama uygulamasındaki bir hata yüzünden her istek, çağıran tarafa yalnızca bir sayfa verilse bile kaç sayfa olduğunu hesaplamak için deponun tüm star'larını sayıyordu. GitHub erişimi sıkılaştırmadan önceki haftada neredeyse 37.000 bu türden sayım sorgusu log'lanacak kadar yavaştı ve ortalama her biri neredeyse üç saniye sürüyordu; veritabanı korumaları bunların 1.000'den fazlasını sonlandırarak istek timeout'larına katkıda bulundu.

Ayrıca bir veri modeli uyuşmazlığı da vardı: biri star'ını kaldırdığında star kaydı siliniyordu, yani endpoint mevcut durumu yansıtıyordu, bir event log değil; oysa araçlar bunu bir zaman serisi olarak ele alıyordu.

Araçları bozan erişim değişikliği

GitHub'ın ilk çözümü, stargazer ve watcher listelerini depo yöneticileri ve iş birlikçileriyle sınırlamak oldu; izni olmayan çağıranlar artık boş bir yanıt ya da 403 Forbidden alıyor. Bu, veri toplama yolunu kapattı ve yükü azalttı — stargazer istekleri yaklaşık yüzde 60, sayım sorgusunda harcanan toplam süre yaklaşık yüzde 80 düştü — ama hiçbir zaman kullanıcı adı göstermeden trend hesaplamak için eski yanıtı kullanan Star History gibi araçları da kesti. GitHub, maintainer'lar ve araç geliştiricileriyle yapılan görüşmelerin, ihtiyaç duydukları şeyin aslında eğrinin kendisi olduğunu gösterdiğini söylüyor: kimlikler değil, yararlı bir çözünürlükte sayılar ve tarihler.

Daha az alan döndürmek neden yeterli olmadı

Kimlikleri bırakmak gizliliği çözdü ama maliyeti çözmedi ve GitHub Blog reddedilen alternatifleri tek tek anlatıyor. Star başına tek kayıt tutup yalnızca timestamp döndürmek mevcut araçların çalışmaya devam etmesini sağlardı, ama istemciler bir toplam oluşturmak için yine de binlerce kaydı sayfalayacaktı. Sayfalamadan önce günlük ya da haftalık kovalara toplamak daha iyi görünüyordu; ne var ki düz bir SQL sorgusunda LIMIT ve OFFSET, veritabanı eşleşen her star'ı bulup grupladı ve sıraladıktan sonra uygulanıyor — dolayısıyla anonim bir istek, bir avuç kova döndürmek için yine de dev bir indeksi tarayabilirdi. react/react için bu yaklaşım kabaca 6 milyon satır inceleyecekti, çünkü 24 isteğin tümü star setinin tamamını yeniden işleyecekti.

Yayınlanan tasarım

Yayınlanan endpoint takvim haftasına göre sayfalanıyor. Her istek, page ve per_page parametrelerini indeksli bir created_at aralığına çeviriyor, star'ları o haftalara göre filtreliyor ve ancak o zaman eşleşen satırları günlük sayılara grupluyor. Tarih filtresi aggregation'dan önce çalıştığı için bir istek, deponun mevcut tüm star'ları yerine yalnızca döndürdüğü haftaları işliyor. Yüksek sayfa numaraları, deponun geçmişinde daha geriye gidiyor.

Ortak bir çözüm

star-history.com'u yöneten ve Bytebase'in kurucu ortağı olan Tianzhou Chen'e göre, araçta yaşanan aksaklık topluluğun proje etrafında kenetlenmesini tetikledi. GitHub'ın topluluk ekibi maintainer'ları ürün mühendisliğiyle buluşturdu ve taraflar amaç özel endpoint'i birlikte tasarlayarak yıkıcı bir değişikliği ortak bir yeniden tasarıma dönüştürdü. Onun anlatısı GitHub Blog yazısında yer alıyor.

Neden önemli

Bu olay, gizlilik ve performansın aynı anda düzeltilmesinin derli toplu bir vaka çalışması: gizlilik sorunu, mevcut bir payload'dan alanları karartarak değil, API sözleşmesini tüketicilerin gerçekten ihtiyaç duyduğu şeyin etrafında yeniden tasarlayarak çözüldü. Ayrıca bir veritabanı dersi de sergiliyor: bir yanıtı küçültmek arkasındaki işi küçültmüyor ve filtreleme aggregation'dan önce gerçekleşmek zorunda, yoksa servis maliyeti yine depo popülerliğiyle ölçekleniyor. Son olarak, güvenlik motivasyonlu bir API değişikliğinin yan hasarını ele almanın bir yolunu gösteriyor: GitHub gerçek araçları bozdu, sonra onları 403 ile baş başa bırakmak yerine maintainer'larıyla birlikte bir yedek üzerinde çalıştı.