Blog

Yapay zeka ajanları için geliştirilen hafif tarayıcı motoru Kitesurf açık kaynak hale geldi. Apache 2.0 lisansıyla yayımlanan proje, sunucusuz (serverless) edge fonksiyonları üzerinde çalışan durumsuz bir tarayıcı motoru sunuyor. Böylece geliştiriciler kodu okuyabiliyor, yerelde çalıştırabiliyor, kendi ihtiyaçlarına göre değiştirebiliyor ve kendi örneklerini kendi bulut hesaplarına dağıtabiliyor.

Bu duyuru, birkaç ay önce paylaşılan erken sürüm ve ardından gelen WebMCP desteği, yeni API’ler ve uyumluluk iyileştirmeleriyle atılan adımların devamı niteliğinde. Projenin ana iddiası net: tam teşekküllü bir tarayıcıyı container içinde çalıştırmadan, web sayfalarını ayrıştırabilen, CSS uygulayabilen, sayfa JavaScript’ini yürütebilen ve ekran görüntüsü üretebilen bir motor. Yani ajanların web’i kullanması için gereken çekirdek yetenekler korunurken, kaynak tüketiminin ciddi biçimde düşürülmesi hedefleniyor.

Kitesurf Nedir ve Ajanlar İçin Neden Farklı

Klasik otomasyon yaklaşımında bir Chrome veya Chromium süreci başlatılır, sayfa yüklenir, DOM üzerinde işlem yapılır ve iş bitince süreç kapatılır. Bu yöntem güvenilirdir ancak pahalıdır: her oturum yüzlerce megabayt bellek tüketir, soğuk başlatma süreleri uzar ve yatay ölçekleme maliyetli hale gelir. Kitesurf ise tarayıcıyı bir süreç olarak değil, bir servis katmanı olarak ele alıyor. HTML ayrıştırma, CSS cascade ve hesaplanmış stiller, düzen (layout), boyama (paint) ve ekran görüntüsü üretimi ayrı paketlere bölünmüş durumda; her biri sunucusuz fonksiyonlar içinde çalışacak şekilde tasarlanmış.

Bu mimarinin ajanlar açısından anlamı şu: Bir agentic yapay zeka akışında tarayıcı genellikle kısa süreli, çok sayıda ve dalgalı bir yük oluşturur. Ajan bir sayfayı okur, birkaç etkileşim yapar, içeriği özetler ve oturumu kapatır. Bu profilde sürekli açık duran bir tarayıcı container’ı boşa kaynak harcar. Durumsuz motor, istek bazlı ölçeklenmeye daha uygun bir zemin sağlar.

Sunucusuz Mimari: Container Yok, Durum Yok

Projenin en dikkat çekici yanı, hiçbir aşamada tarayıcı container’ı gerektirmemesi. Motor tamamen edge üzerindeki sunucusuz fonksiyonlarda çalışıyor. Bu, iki pratik sonuç doğuruyor:

• Soğuk başlatma yönetimi kolaylaşıyor: Container imajı indirme, işletim sistemi katmanı hazırlama gibi adımlar ortadan kalkıyor.
• Maliyet modeli değişiyor: Faturalama, açık kalan süre yerine çalıştırılan hesaplama üzerinden şekilleniyor; kısa görevler için avantaj, ağır ve uzun oturumlar için ise dikkat gerektiren bir tablo.

Buna karşılık durumsuzluk, oturum yönetimini geliştiricinin sorumluluğuna bırakıyor. Çerezler, oturum açma durumu, sayfalar arası gezinme geçmişi gibi verilerin nerede saklanacağı ve nasıl taşınacağı tasarım kararı haline geliyor. Bu, klasik headless tarayıcı alışkanlıklarıyla gelen ekipler için başlangıçta ek iş demek; ancak yatay ölçekleme ve çok kiracılı (multi-tenant) kullanım açısından belirgin bir esneklik sağlıyor.

Deponun İçinde Ne Var

Açık kaynak depo, tek bir monolit değil; Rust ile yazılıp WebAssembly’ye derlenen açık kaynak paketlerin bir araya getirildiği bir bütün. Temel taşlar şunlar:

• Blitz: HTML ayrıştırma, DOM ağacı, düzen ve boyama katmanını sağlıyor.
• Stylo: CSS ayrıştırma, cascade ve hesaplanmış stillerden sorumlu. Tarayıcı motorlarında olgunluğu kanıtlanmış bir bileşen.
• Boa: JavaScript yürütme katmanı. Yalnızca JavaScript’in dinamik fonksiyon ortamında çalıştırılamadığı son çare durumlarda devreye giriyor.
• Linebender kütüphaneleri ve Krilla: Metin düzeni, 2B grafik çizimi ve PDF çıktısı üretimi.

Bu bağımlılıklar kendi lisanslarını koruyor; depodaki NOTICE dosyası üçüncü taraf bildirimlerini belgeliyor. Kendi ürününüze entegre etmeyi planlıyorsanız lisans uyumluluğunu baştan kontrol etmeniz yerinde olur; Apache 2.0 görece rahat bir lisans olsa da, alt bileşenlerin şartları ayrı ayrı geçerli.

Üç Ana Bileşen: Engine, PageScript ve PageRenderer

Mimari zihinsel olarak üç parçaya ayrılıyor ve bu ayrım, dağıtım stratejinizi belirlerken işinizi kolaylaştırıyor:

• Engine: Tarayıcı oturumlarını ve istemci bağlantılarını yönetir. Protokol tarafının ve yaşam döngüsünün sahibi burası.
• PageScript: Sayfayı ve sayfadaki JavaScript’i çalıştırır. Yalıtım (isolation) ve kaynak sınırları açısından en hassas bileşen.
• PageRenderer: Ortaya çıkan sonucu çizer; ekran görüntüsü ve PDF gibi çıktıların üretildiği yer.

Tüm paketler, Rust çekirdeği, DOM shim’leri, renderer ve komut satırı aracı depodaki paketler dizininde ayrı klasörlerde duruyor. Bu düzen, parçaların birbirine nasıl bağlandığını kaynak kodu üzerinden takip etmek isteyenler için okunabilir bir harita sunuyor.

Kendi Kitesurf Kopyanızı Çalıştırma

Yerelde denemek için derleme gereksinimlerini karşıladıktan sonra depoyu klonlayıp bağımlılıkları kurmak ve geliştirme sunucusunu başlatmak yeterli:

git clone <depo-adresi>
cd kitesurf
pnpm install --frozen-lockfile
pnpm run dev

İlk derleme, Rust çekirdeğini ve bağımlılıklarını derlediği için uzun sürebilir; sonraki derlemeler önbelleği yeniden kullanır. Geliştirme sunucusu varsayılan olarak 127.0.0.1:8787 adresinde açılır. Bu adresi tarayıcıdan ziyaret ederek motoru elle deneyebilir, aynı adresi programatik olarak da kullanabilirsiniz. Üretime alırken dikkat edilmesi gereken nokta, gizli anahtarların ve yapılandırmanın kaynak koduna değil ortam değişkenlerine taşınması.

Mevcut Otomasyon Araçlarıyla Uyum: CDP ve Puppeteer

Yeni bir motor benimsemenin en büyük engeli, mevcut test ve otomasyon altyapısını yeniden yazma zorunluluğudur. Proje bu riski Chrome DevTools Protocol (CDP) desteğiyle azaltıyor. CDP üzerinden konuşabilen istemciler, yani Puppeteer gibi yaygın araçlar, Kitesurf örneğine bağlanabiliyor. Pratikte bu, halihazırda yazılmış betiklerin büyük bölümünün küçük uyarlamalarla çalışabileceği anlamına geliyor:

import puppeteer from "puppeteer-core";

const browser = await puppeteer.connect({
  browserWSEndpoint: "ws://127.0.0.1:8787/..."
});

Yine de tam uyumluluk beklememek gerekir. CDP geniş bir protokoldür ve motorun kapsamı bilinçli olarak dar tutulmuş. Karmaşık WebGL sahneleri, ağır video oynatma, özel yazı tipi yükleme senaryoları veya gelişmiş ağ koşullandırma gibi konularda farklılıklar çıkabilir. Entegrasyon öncesi kendi kritik akışlarınız için bir uyumluluk testi yazmanız, sonradan sürpriz yaşamamanın en kısa yolu.

Geleneksel Headless Tarayıcı ile Karşılaştırma

Kriter	Geleneksel headless tarayıcı	Kitesurf
Çalışma biçimi	Container içinde tam tarayıcı süreci	Sunucusuz edge fonksiyonları
Bellek ayak izi	Yüksek, oturum başına sabit maliyet	Düşük, istek bazlı paylaşım
Ölçeklenme	Havuz yönetimi ve kapasite planlaması gerekir	Talep üzerine yatay ölçeklenme
Uyumluluk kapsamı	Çok geniş, tüm modern web özellikleri	Hedefe yönelik, ajan odaklı alt küme
Durum yönetimi	Oturum içinde doğal olarak korunur	Geliştiricinin tasarlaması gerekir
Kurulum maliyeti	İmaj, sürücü ve bağımlılık yönetimi	Depo klonu ve bağımlılık kurulumu
Uygun kullanım	Karmaşık SPA testleri, görsel regresyon	İçerik çıkarma, form doldurma, hafif gezinme

Üretim Ortamında Dikkat Edilmesi Gerekenler

Açık kaynak olması, üretimde düşünülmesi gerekenleri ortadan kaldırmıyor. Ajanların web’e çıkması beraberinde hem teknik hem de etik yükümlülükler getiriyor:

• Yürütme süresi sınırları: Sunucusuz fonksiyonların üst sınırları vardır. Uzun sayfalar ve ağır JavaScript, tek bir çağrıyı aşabilir; işi parçalara bölmek gerekir.
• Kimlik ve yetkilendirme: Motorun dışarıya açık bir uç nokta olarak çalışması, yetkisiz kullanım riski doğurur. İmzalı istekler ve hız sınırları zorunlu hale gelir.
• Gizli bilgi yönetimi: Oturum çerezleri ve API anahtarları asla istemci tarafına sızmamalı.
• Site politikaları: Hedef sitelerin kullanım şartlarına ve bot kurallarına uyum, hukuki ve operasyonel bir gereklilik. Erişim politikalarını baştan netleştirmek için yapay zeka ajanı erişim politikaları rehberi iyi bir başlangıç noktası olabilir.
• Çıktı doğrulama: Ekran görüntüsü ve PDF üretimi kaynak tüketir; her adımda görüntü almak yerine yalnızca gerektiğinde tetiklemek maliyeti düşürür.

Hangi Senaryolarda Tercih Edilmeli

Motorun güçlü olduğu yer, sayfayı insan gözüyle değil bir görev bağlamında ele alan akışlar. Örneğin bir fiyat izleme ajanı, form doldurup gönderen bir iş akışı, içerik çıkarma ve özetleme hatları, erişilebilirlik kontrolleri veya toplu sayfa doğrulama işleri bu profile uyar. Buna karşılık görsel regresyon testleri, karmaşık tek sayfa uygulamalarının derin senaryoları, video tabanlı doğrulamalar ve tarayıcı eklentisi gerektiren işler için geleneksel bir headless tarayıcı hâlâ daha güvenli bir tercih. Doğru yaklaşım, iki modeli birbirinin alternatifi değil, farklı iş yükleri için tamamlayıcı araçlar olarak görmek.

Barındırma Tarafında Nerede Çalıştırmalı

Kitesurf’ün bir kısmı edge fonksiyonlarında çalışsa da, kendi kopyanızı barındırırken yanında yardımcı servisler gerekir: kuyruk yönetimi, oturum deposu, kimlik doğrulama katmanı, log toplama ve vekil (proxy) çıkışları. Bu bileşenler için esnek bir VPS hosting ortamı çoğu senaryoda yeterli olur; yoğun ekran görüntüsü üretimi veya paralel render işleri varsa kaynakları ayrılmış bir dedicated sunucu daha öngörülebilir performans sağlar. Ölçeklendirme kararını verirken ortalama değil, en yoğun saatteki eşzamanlı oturum sayısını esas almak yanıltıcı olmaz.

SSS

Kitesurf tam bir tarayıcı mı?

Hayır. Ajanların web sayfalarıyla etkileşimi için gereken çekirdek yetenekleri sunan hafif bir motor. Tüm modern web özelliklerini birebir desteklemeyi hedeflemiyor; kapsamı bilinçli olarak dar tutulmuş.

Hangi lisansla yayımlandı?

Apache 2.0 lisansıyla. Bu, ticari projelerde kullanım ve değiştirme açısından geniş özgürlük tanır; ancak içerdiği üçüncü taraf bileşenlerin kendi lisansları ayrıca geçerlidir.

Yerelde çalıştırmak için ne gerekiyor?

Depoyu klonlayıp bağımlılıkları kurmanız yeterli. İlk derleme Rust çekirdeğini derlediği için uzun sürer, sonraki derlemeler önbellekten yararlanır. Geliştirme sunucusu 8787 portunda açılır.

Mevcut Puppeteer betiklerim çalışır mı?

Büyük ölçüde çalışabilir, çünkü motor Chrome DevTools Protocol üzerinden bağlantı kabul ediyor. Yine de protokolün tamamı uygulanmadığı için kritik akışlarınızı uyumluluk testinden geçirmeniz gerekir.

Açık kaynak olması güvenlik açısından ne değiştirir?

Kodu denetleyebilme imkânı sağlar, ancak sorumluluğu ortadan kaldırmaz. Dışarıya açık bir uç nokta çalıştırıyorsanız kimlik doğrulama, hız sınırlama ve gizli bilgi yönetimini kendiniz kurgulamalısınız.