Colly İncelemesi: Statik HTML, Doğrudan JSON ve Tarayıcı Sınırı

Colly’nin bir sayfa sayısı ya da hız iddiasıyla cevap veremediği noktaları sınamak için bir fixture sitesi kurdum: callback’lerinin beklenen kayıtları çıkarıp çıkarmadığını, HTTP hatasını doğru yere yönlendirip yönlendirmediğini, sınırlandırılmış bir grafiği takip edip etmediğini ve render edilmiş HTML dışında sunulan içeriği açığa çıkarıp çıkaramadığını kontrol ettim. Bu çalışma hızdan çok; doğruluk ve sınır kontrolleri üzerineydi.

Kontrollü fixture’larda beklenen tüm statik kayıtları eksiksiz çıkardı, bir 500 yanıtını OnError’a yönlendirdi ve derinlik sınırı tanımlanmış grafikte 17 URL ziyaret etti. JavaScript çalıştıktan sonra görünen öğeleri olan iki sayfada ise hedef öğe sayısı sıfır döndü. Doğrudan erişilebilen bir JSON uç noktası ise tarayıcıya gerek kalmadan kullanılabildi; bu da istemci arayüzünü render etmekten önemli bir fark.

Colly tam olarak nedir?

Colly kendini “Golang için zarif bir scraper ve crawler framework’ü” olarak tanımlıyor; bu ifade göründüğünden daha fazlasını anlatıyor. Yaklaşık 25.300 GitHub yıldızı ve 1.850 fork’a sahip, Apache-2.0 lisanslı bir Go kütüphanesi. İndirip bir URL’ye yönelteceğiniz bir CLI değil. Go kodu yazarsınız, Colly’yi içe aktarırsınız, birkaç callback kaydedersiniz ve her şeyi tek bir çalıştırılabilir dosya olarak derlersiniz.

Zihinsel modeli olay güdümlüdür. Collector üzerine handler’lar eklersiniz: OnHTML eşleşen CSS seçiciler için çıkarım mantığını çalıştırır, OnResponse ham yanıt gövdesini verir, OnError ise istek hatalarını yakalar. Link handler’ları bulunan URL’ler için Visit() çağırır; MaxDepth ise gezintiyi sınırlar. Bu yapı yalnızca HTTP ile çalışan yollar için hedef host’ta ayrıca kurulmuş bir Go runtime ya da tarayıcı gerektirmez; çalıştırılabilir dosyanın tamamen statik olup olmadığı ise build flag’lerine ve CGO kullanımına bağlıdır; bu test bunu kaydetmedi.

Temel özellikler ve perde arkasında nasıl çalıştıkları

Callback modeli, Colly’nin neden sıradan bir istek-ve-ayrıştır betiğinden farklı hissettirdiğini anlamak için kilit nokta. Yaptığım tüm testlerde üç callback belirleyici oldu.

OnHTML(selector, handler) işin ana motorudur. Bunu .product ya da article p için kaydettiğinizde, Colly DOM’u ayrıştırırken eşleşen her öğe için handler’ınızı bir kez çalıştırır. Yapılandırılmış veri çıkarımı burada yaşar; yani bir parse döngüsü yazmak yerine neyi almak istediğinizi söylersiniz.

OnResponse(handler) bir katman aşağıdadır ve size ham baytları verir. Bir hedef HTML yerine JSON döndürdüğünde DOM’u tamamen atlar, gövdeyi kendiniz unmarshal edersiniz. Colly’nin testimde herhangi bir HTML ayrıştırmasına gerek kalmadan bir JSON API’yi sorunsuz işlemesini sağlayan tek callback buydu.

OnError(handler) istek hatalarını ele alır ve çağıran koda bir yanıt durumu aktarabilir. Bu testte durum kodu 500 olan bir fixture yanıtı kayıtlı callback’e ulaştı. Yeniden denemeler, zaman aşımı, DNS hataları, bağlantı sıfırlamaları, callback panic’leri, kalıcılık ve uyarı mekanizmaları test edilmedi.

Callback’lerin üzerinde iki operasyonel özellik bulunur. MaxDepth, Colly’nin derinlik semantiğine göre link gezintisini sınırlar. Derlenmiş bir Go çalıştırılabilir dosyası da hedef makinede ayrıca kurulmuş bir dil runtime’ı ihtiyacını ortadan kaldırır. Bu çalıştırmada build flag’leri veya CGO durumu kaydedilmediği için, ortaya çıkan her binary’nin tamamen statik olduğunu iddia etmiyorum.

Kurulum: gerekli Go araç zinciri

Bağımlılık hikâyesi kısa ama gerçek; o yüzden bir şey kurmadan önce burada anlatayım. Test yaptığım makinede Go yüklü değildi ve Colly bir Go kütüphanesi olduğu için ilk adım kutuya bir Go toolchain kurmaktı (Homebrew ile Go 1.26.5 kurdum). Ekibiniz zaten Go dünyasında yaşamıyorsa, asıl sürtünme Colly’nin kendisi değil; tek bir satır bile derlenmeden önce ihtiyaç duyduğu dil ortamı.

Go kurulduktan sonra go get github.com/gocolly/colly/v2, v2.3.0’a çözümlendi. Test edilen yollar için tarayıcı ya da headless Chrome gerekmedi.

Bir sürüm yüzeyi kafa karıştırabilir. Go modülü v2.3.0’a çözümlendi (Aralık 2025’te yayınlanmış), ancak kontrol edildiğinde GitHub Releases arayüzünde görünen en yeni kayıt v2.2.0 idi (Mart 2025). Buradaki fark modül/depo sürümü ile GitHub Release kaydı arasındadır; modül ile Git tag’i arasında değil. Ben v2.3.0’ı test ettim.

Uygulamalı test: çıkarım ve çalışma sınırları

Colly’yi kendi kendine yeten bir fixture sunucusu (Go’nun httptest) ve iki kamuya açık demo site üzerinde çalıştırdım. Mevcut benchmark dizini ve results/colly-test-summary.json çıktıları gösteriyor; ancak her iki bağlantı da hareketli bir branch’e gidiyor. Makale test edilmiş bir commit, kesin komut, build flag’leri veya fixture seed’i vermiyor; dolayısıyla bu henüz değişmez bir yeniden üretim tarifi değil.

Kontrollü statik fixture’larda, tanımlı seçiciler 12/12 beklenen ürün kaydını ve üç beklenen makale paragrafının tamamını üretti. Doğrudan JSON yanıtında hiçbir zaman HTML ayrıştırıcıya dokunulmadı: OnResponse gövdeyi sağladı ve harness sekiz beklenen öğenin tamamını decode etti. Tek bir 500 fixture, durumuyla birlikte OnError’a ulaştı ve çalıştırmayı çökertmedi; ancak bu, gözetimsiz güvenilirlik anlamına gelmez. Kamuya açık Books to Scrape sayfasında ise seçici, genel site için bir sağlık kontrolü olarak 20 ürünü döndürdü.

Gezinti için collector, harness’in seed-depth kuralı ile MaxDepth(2) olarak ayarlandı ve fixture grafiğinde 17 URL ziyaret etti. Bu sonuç hız değil, crawl kapsamasıdır. Daha geniş bir grafik iddiası değil, gözlemlenen iz results/local_crawl_graph.json içindedir.

Colly JavaScript çalıştırmaz. JavaScript ile render edilen fixture 0 hedef kart üretti; kamuya açık Quotes to Scrape JS page ise 0 hedef alıntı döndürdü. Öğeler yalnızca tarayıcı çalıştırıldıktan sonra ortaya çıkıyorsa ve erişilebilir bir arka uç uç noktası bunları sunmuyorsa, yalnızca HTTP yoluyla çalışan bir araç bu öğeleri render edilmiş DOM olarak göremez. Bir renderer ile birlikte kullanın ya da varsa doğrudan arka uç uç noktasını çağırın; JSON fixture bunu gösteriyor.

Async collector’ı, hız limiti ya da nezaket ayarlarını, proxy rotasyonunu, yeniden denemeleri veya kuyruk ve depolama arka uçlarını zorlamadım. Geçen süre, throughput, concurrency, CPU, bellek, hedef gecikmesi ya da bir karşılaştırma baz çizgisi ölçülmedi. Bu yüzden bu makale hız veya gözetimsiz güvenilirlik iddiasında bulunmuyor.

Fixture sonuçlarını nasıl yorumlamalı?

Başarıyla geçen üç içerik yolu farklı sözleşmeleri test ediyor. Katalog ve makale örnekleri, sunucunun döndürdüğü HTML üzerinde CSS seçimi yapmayı ölçüyor. Bu testlerin paydası, çıkarımdan önce yazılmış fixture beklentileri: on iki ürün kaydı ve üç makale paragrafı. Bunları “beklenen kayıtlar çıkarıldı” diye raporlamak bilinçli bir tercih. Çalışma, belirsiz eşleşme, tekrar kayıt işleme, kısmi alan toleransı ya da tüm korpusa yayılan bir geri çağırma metriği tanımlamıyor; bu nedenle sonuç genel çıkarım doğruluğuna dönüştürülmemeli.

JSON örneği DOM seçimini tamamen atlıyor. Colly yanıt baytlarını OnResponse üzerinden alıyor, JSON çözümlemeyi harness yapıyor. Bu yüzden “Colly JavaScript çalıştırmaz” ifadesi, istemciye bağlı her sitenin ulaşılamaz olduğu anlamına gelmez. İstemcinin kullandığı veri kaynağı doğrudan çağrılabilir bir uç nokta ise ve istek tarayıcı dışında da yeniden üretilebiliyorsa, HTTP crawler hâlâ yeterli olabilir. Kimlik doğrulama, üretilen imzalar, yalnızca tarayıcıya özgü durum ve anti-bot kontrolleri bu yanıtı değiştirebilir; burada hiçbiri test edilmedi.

500 yönlendirmesi kurtarmayı değil, yönlendirmeyi test ediyor. Kayıtlı OnError callback’inin o fixture yanıtını ve durumunu aldığını gösteriyor. Üretim ortamındaki bir crawler’ın yine de yeniden denenebilir kodlar, backoff, terminal hatalar, kalıcılık ve uyarılar için açık bir politikaya ihtiyacı var. Test bu seçimler için hiçbir kanıt sunmuyor; “callback çalıştı” ifadesi “iş gözetimsiz güvenilir biçimde çalışır” diye okunmamalı.

17 URL’lik grafik de benzer biçimde dar kapsamlı. Bu, bu fixture, bu seed kuralı ve MaxDepth(2) ile üretilen ziyaret kümesini doğrular. Saniyedeki sayfa sayısını, hostlar arasında adaleti, bellek büyümesini ya da döngüler ve yinelenen URL biçimleri üzerindeki davranışı göstermez. Bunlar ayrı iş yükü ve kuyruk testleri gerektirir.

Bu çalışmaya dayalı seçim kontrol listesi

İşe Colly’nin gerçekten aldığı yanıtla başlayın. Gerekli alanlar sunucunun döndürdüğü HTML’de varsa OnHTML kullanın ve bir kaydı kabul etmeden önce alan sayısını ya da gerekli anahtarları doğrulayın. Yanıt JSON ise gövdeyi OnResponse üzerinden işleyin ve şemasını doğrulayın. HTML sadece bir uygulama kabuğuysa, tarayıcı eklemeden önce erişilebilir bir arka uç isteğinin veriyi içerip içermediğini kontrol edin.

Tarayıcı çalıştırma gerekiyorsa, bunu Colly’de bir bayrakla açılan özellik gibi değil, başka bir bileşen gibi ele alın. Tarayıcının hazır durumu sağlaması, render edilmiş içeriği ya da arka uç yanıtlarını açığa çıkarması ve veriyi boru hattının geri kalanına aktarması gerekir. Bu inceleme böyle bir entegrasyonu test etmedi.

Dağıtıma geçerken Go sürümünü, modül sürümünü, build flag’lerini, CGO durumunu, kesin komutu, fixture seed’ini ve depo commit’ini kaydedin. Bu ayrıntılar mevcut yayın bağlantılarında eksik ve denetlenebilir çıktılar ile kalıcı bir yeniden üretim arasında fark yaratıyor. Operasyon tarafında ise bir hata matrisi ekleyin ve sistemi hızlı ya da güvenilir ilan etmeden önce gerçekten önemsediğiniz iş yükünü ölçün.

Artılar ve eksiler

Artılar:

• OnHTML üzerinden beklenen katalog ürünlerinin 12/12’si ve beklenen makale paragraflarının 3/3’ü çıkarıldı.
• OnResponse ile temiz JSON işleme; DOM ayrıştırması gerekmedi — 8/8 API öğesi.
• Test edilen 500 yanıtı, durum bilgisi görünür şekilde OnError’a ulaştı.
• Derinlik sınırlandırılmış crawl, tek bir collector ile 17 sayfaya ulaştı.
• Go çalıştırılabilir dosyası olarak derlenir; test edilen yollarda hedefte ayrıca kurulmuş bir Go runtime gerekmez.
• Apache-2.0 gibi esnek bir lisansa sahip.

Eksiler:

• JavaScript çalıştırmaz — istemci tarafında render edilen içerik doğrudan 0 döner.
• Go toolchain gerekir; Go kullanmayan ekipler, tek bir scraper yazmadan önce bu kurulum maliyetini öder.
• Test edilen modül (v2.3.0), gözlemlenen en yeni GitHub Release kaydından (v2.2.0) ileride.
• Çıktı sizin kendi kodunuzdur — Colly size callback’ler verir; Scrapy’deki gibi yerleşik bir veri seti/akış dışa aktarıcısı değil.
• Async, hız limiti, proxy ve kuyruk arka uçları mevcut ama burada test edilmedi; throughput ve ölçek ölçülmedi.

Kimler için uygun — kimler pas geçmeli?

Colly, zaten Go yazıyor ve sunucunun render ettiği HTML ya da doğrudan erişilebilir JSON hedefliyorsanız uygundur. Callback modeli, yapılandırılmış eşleşmeleri, ham yükleri ve istek hatalarını birbirinden ayırır. Derlenmiş bir çalıştırılabilir dosya da hedef makinede ayrıca kurulmuş bir dil ortamına duyulan ihtiyacı kaldırır; ancak burada tam statik bağlama doğrulanmadı.

Gerekli hedef öğeler yalnızca tarayıcı çalıştırıldıktan sonra ortaya çıkıyorsa ve kullanılabilir bir arka uç uç noktası yoksa bir renderer ekleyin. Doğrudan JSON uç noktası ise yine de render etmeden çağrılabilir. Go toolchain istemeyen ya da çıkarım hizmetinin şema biçimlendirmesi ve seçici bakımını üstlenmesini isteyen ekipler için Colly daha zayıf bir tercihtir.

Alternatifler ve Thunderbit’in konumu

Colly, kendi kendinize çalıştırdığınız açık kaynak yazılımdır. Herhangi bir lisans kullanım ücreti yoktur; ancak compute, bant genişliği, proxy, depolama, gözlemlenebilirlik ve mühendislik maliyeti size aittir. İstek davranışı, ayrıştırma callback’leri, crawl mantığı ve gerekiyorsa tarayıcı entegrasyonu sizin sorumluluğunuzdadır.

Yönetilen bir çıkarım hizmeti bu sorumlulukların bir kısmını satıcıya taşır. Biz Thunderbit geliştiriyoruz; ancak bu fixture’lara karşı test etmedik, dolayısıyla bu makale render, anti-bot, kalite, gecikme ya da maliyet karşılaştırması yapmıyor. Desteklenen fark sahipliktir: Colly, HTTP yanıtlarını ve callback’leri sizin Go sürecinizde sunar; yönetilen bir hizmet ise veri edinme ve şema biçimlendirmesini çağrı başına bir ücret karşılığında üstlenebilir.

İlgili benchmark incelemeleri: tam açık kaynak scraper karşılaştırması, Scrapy’nin Python crawler incelemesi ve Scrapling’in adaptif seçici incelemesi.

Web Verisi Çıkarma için Thunderbit’i Deneyin

Sonuç

Colly, sunucu tarafında render edilen HTML ya da doğrudan JSON hedefleyen ve çıkarım kodunun sorumluluğunu üstlenmeye hazır Go ekipleri için güçlü bir adaydır. Fixture’lar, beklenen kayıt çıkarımını, bir adet sınırlandırılmış crawl izini ve gözlemlenen bir 500 callback’ini destekliyor; hız, ölçek ya da gözetimsiz güvenilirlik değil. Alttaki veri uç noktası doğrudan çağrılabiliyorsa, tarayıcıyla render edilen DOM için başka bir yol gerekir.

Web Verisi Çıkarma için Thunderbit’i Deneyin Get Started Free

SSS

Bu inceleme Colly’nin hızını ölçtü mü? Hayır. Beklenen kayıt çıkarımını, doğrudan JSON işlemeyi, bir hata callback’ini ve fixture crawl grafiği kapsamını ölçtü. Geçen süreyi, throughput’u, concurrency’yi, CPU’yu, belleği ya da bir karşılaştırma baz çizgisini ölçmedi.

Colly JavaScript ile render edilen sayfaları scrape edebilir mi? Colly sayfanın JavaScript’ini çalıştırmaz. Bu yüzden test edilen HTTP yolu, yalnızca render edilmiş DOM’da görünen hedef öğeleri bulamadı. Ancak JSON fixture’ın gösterdiği gibi, erişilebilir bir arka uç JSON uç noktasını doğrudan isteyebilir. Çalıştırma gerekiyorsa ve yeniden üretilebilir bir arka uç isteği veri sağlamıyorsa bir renderer kullanın.

Colly kullanmak için Go bilmem gerekir mi? Evet. Colly bağımsız bir CLI değil, bir Go kütüphanesidir — içe aktarırsınız, callback’leri (OnHTML, OnResponse, OnError) kaydedersiniz ve derlersiniz. Test yaptığım makinede Go yoktu; kurulum Go toolchain’i (1.26.5) yüklemekle başladı. Ekibiniz zaten Go’da değilse, gerçek kurulum maliyeti bu ortamdır.

Kurduğum sürüm neden Colly’nin en yeni GitHub release’iyle eşleşmiyor? Go modülü v2.3.0’a çözümlendi (Aralık 2025), ancak gözlemlenen en yeni GitHub Release kaydı v2.2.0 idi (Mart 2025). Ben v2.3.0’ı test ettim; bu, sürüm yüzeyleri arasındaki farktır, hatalı kurulumun kanıtı değildir.

Colly ticari kullanım için ücretsiz mi? Evet, Apache-2.0 lisanslıdır; esnek ve ticari kullanıma uygundur. Her zamanki gibi, üzerine inşa etmeden önce depodaki güncel lisansı doğrulayın.

Üretimde kullanmadan önce, fixture sonucunu analojiyle uzatmak yerine gerçek operasyon riskine uygun testler ekleyin. Temsil edici hedeflerde tekrarlanan crawl’ları zamanlayın, CPU ve tepe bellek kullanımını kaydedin, yeniden denenebilir ve terminal hataları çalıştırın, concurrency altında nezaket davranışını doğrulayın. Kalıcılık önemliyse, yinelenen kayıt işleme ve kuyruk durumunu incelerken bir crawl’u durdurup yeniden başlatın. Dağıtım basitliği önemliyse, tam derleyici ve bağlayıcı yapılandırmasını kaydedin ve üretilen çalıştırılabilir dosyanın çalışma zamanı bağımlılıklarını inceleyin. Bu kontrollerin hiçbiri mevcut fixture’ın neyi ortaya koyduğunu değiştirmez; yalnızca aynı kütüphane konfigürasyonunun belirli bir üretim işi için uygun olup olmadığını gösterir.