goldsky-go, Goldsky'nin blockchain veri API'lerine bağımlılıksız bir Go istemcisi getiriyor

Goldsky için topluluk geliştirimi bir Go istemcisi

Goldsky üzerinden blockchain verisi tüketen Go servisleri genellikle aynı HTTP altyapı kodunu biriktirir: yetkilendirme başlıkları, retry kararları, sayfalama token'ları ve JSON-RPC zarfı kontrolleri. dev.to'da yayınlanan bir yazıda tanıtılan goldsky-go adlı yeni topluluk SDK'sı, bu entegrasyon işini tek bir idiomatik Go istemcisinde topluyor; böylece ekipler dikkatlerini ürün mantığına ayırabiliyor.

Kütüphane resmi bir Goldsky paketi değil, bağımsız olarak korunuyor ve github.com/tigusigalpa/goldsky-go adresinde yer alıyor. Duyuruya göre, Goldsky REST API'sinin 1.2.0 sürümünü hedefliyor ve belgelenmiş 40 REST operasyonunun tamamını kapsıyor; ayrıca Subgraph GraphQL uç noktalarına ve Goldsky Edge HTTPS JSON-RPC'ye birinci sınıf erişim sağlıyor. Bu, kontrol düzlemi işlerini — pipeline, subgraph, webhook ve Edge uç noktalarını yönetmek — ve veri düzlemi işlerini, örneğin indekslenmiş veriyi sorgulamak veya bir RPC uç noktasını çağırmak, tek bir istemci modelinin arkasına alıyor.

Yalnızca standart kütüphane

Daha ayırt edici tercihlerden biri, goldsky-go'nun hiçbir üçüncü taraf runtime bağımlılığı olmaması. Büyük bir HTTP soyutlama yığını yerine Go standart kütüphanesi üzerine inşa edilmiş; dev.to yazısı bunu, bağımlılık yüzey alanının ve dağıtım basitliğinin önemli olduğu servisler için pratik bir avantaj olarak sunuyor.

Public metotlar context.Context kabul ediyor ve kararlı API biçimleri tipli istek ve yanıt modelleri kullanıyor. Constructor, ağ çağrısı yapmadan seçenekleri doğruluyor; bu da uygulama başlatmayı ve testleri öngörülebilir kılıyor. Öngörülen kullanım biçimi, istemciyi bir proje API token'ı ve uygulamaya uygun bir timeout ile bir kez oluşturup yeniden kullanmak ve her operasyona context üzerinden kendi son tarihinin verilmesi. Kurulum için Go 1.22 veya üzeri gerekiyor.

Tek istemci, yedi servis

Çağıran taraftan uç nokta URL'lerini elle oluşturmasını istemek yerine, SDK işlevselliği servisler halinde düzenliyor:

• Pipelines: Turbo Pipeline'ları doğrulama, oluşturma, inceleme, duraklatma, sürdürme, yeniden başlatma, silme ve gözlemleme
• Subgraphs: bundle deploy etme, sürüm ve etiket yönetimi, indeksleme loglarını ve webhook entity'lerini okuma
• Webhooks: entity webhook'ları oluşturma, listeleme ve silme
• Edge: uç noktaları, anahtarları, yaşam döngüsü aksiyonlarını ve metrikleri yönetme
• Catalogs: kullanılabilir subgraph zincirlerini, Edge ağlarını ve Edge Data kaynaklarını keşfetme
• GraphQL: public veya private Subgraph GraphQL sorguları gönderme
• RPC: Goldsky Edge üzerinden tekil veya toplu JSON-RPC 2.0 çağrıları yapma

Tam bir metot-operasyon eşlemesi, deponun API kapsam dokümanında korunuyor.

Sayfalama ve deploy işlemleri

Sayfalama, Goldsky'nin continuation-token şemasını izleyen pager nesneleriyle yönetiliyor; sonuç kümesinin sonunu sayfa boyutlarından çıkarsamak yerine — kısa bir sayfa her zaman son sayfa olmayabilir. Pipeline, subgraph ve Edge uç noktaları için pager'lar, bir sonraki sayfa token'ı gelmeyene kadar istek atmaya devam ediyor, geçersiz boyutları yerel olarak reddediyor ve son sayfadan sonra gereksiz HTTP istekleri atmak yerine boş bir sayfa döndürüyor. Yazı, yeniden kullanılabilir istemcinin ve servislerinin paylaşılmaya güvenli olsa da pager'ların eşzamanlı kullanım için tasarlanmadığına dikkat çekiyor.

Subgraph deploy işlemi, zip bundle'ı tüm arşivi uygulama belleğinde tamponlamadan multipart/form-data olarak akıtıyor. Deploy işlemleri bilinçli olarak otomatik olarak yeniden denenmiyor: rastgele bir io.Reader mutlaka yeniden oynatılamayabilir ve bir mutasyon üzerindeki belirsiz bir timeout aksi halde yinelenen veya kafa karıştırıcı sonuçlar doğurabilirdi. Önerilen yöntem, ilk denemenin etkili olup olmadığını kontrol etmek, dosyayı yeniden açmak ve ancak ondan sonra yeniden denemektir.

Şemalar uygulamada kalıyor

GraphQL için SDK, sorgu sonuçlarını error'ların, header'ların ve HTTP durum kodunun yanında .RawMessage olarak döndürüyor ve çözümlemeyi (decode) çağırana bırakıyor. Farklı subgraph'ler farklı entity ve alanlar sunduğundan, evrensel tipler üretmek kırılgan olurdu; her uygulama beklediği yapıyı kendisi çözümlüyor ve bu, istemcinin Web3 verisinin tek bir statik şeması olmadığı gerçeğine sadık kalmasını sağlıyor.

Neden önemli

Goldsky, büyüyen bir blockchain indeksleme altyapısı yığınının içinde yer alıyor ve Go, bunun üzerine inşa edilen servisler için yaygın bir tercih. Goldsky ile entegre olan ekipler daha önce HTTP ayrıntılarını elle yazmak ya da API'lerine erişmek için daha ağır bir bağımlılık kabul etmek zorundaydı. goldsky-go bir orta yol sunuyor: belgelenmiş tüm yüzey genelinde tipli, context duyarlı metotlar, sıfır runtime bağımlılığı ve sessiz kolaylığın tehlikeli olduğu tam noktalarda — deploy'ları yeniden denemek, sayfalamayı tahmin etmek ya da tüm subgraph verisinin tek bir şema paylaştığını varsaymak — açık operasyonel kurallar. Bir topluluk projesi olarak uzun vadeli kapsamı, geliştiricisine bağlı; ancak Goldsky verisini Go servislerine taşımanın maliyetini ciddi ölçüde düşürüyor.