Cloudflare, tüm ürünleri kapsayan birleşik bir CLI geliştiriyor

 (blog.cloudflare.com)
5 puan yazan GN⁺ 16 일 전 | 2 yorum | WhatsApp'ta paylaş
  • Cloudflare, 100'den fazla ürünü ve yaklaşık 3.000 HTTP API'sini tek bir birleşik CLI(cf) ile sunmak için yeni nesil Wrangler'ı yeniden inşa ediyor; teknik önizleme şu anda npx cf ile kullanılabiliyor
  • Mevcut OpenAPI şemaları tek başına CLI komutları, Workers binding'leri ve agent skill'leri gibi çeşitli arayüzleri ifade etmeye yetmediği için TypeScript tabanlı yeni bir şema sistemi kullanıma alınıyor
  • Agent'ların CLI'ı başlıca tüketici olarak kullandığı eğilime uygun şekilde, get/--force/--json gibi komut tutarlılığı kuralları ve koruma mekanizmaları şema düzeyinde zorunlu kılınıyor
  • Yerel geliştirme sırasında simüle edilen kaynakların kolayca incelenebilmesini sağlayan Local Explorer özelliği açık beta olarak yayımlandı; KV, R2, D1 gibi yerel veriler doğrudan görülebiliyor
  • Cloudflare, tüm API yüzeyini CLI ve yerel ortamda aynı API biçimiyle tutarlı şekilde sunarak hem agent'lar hem de geliştiriciler için optimize edilmiş bir geliştirme deneyimi hedefliyor

Cloudflare'in API ölçeği ve agent merkezli dönüşüm

  • Cloudflare'in 100'den fazla ürünü ve yaklaşık 3.000 HTTP API operasyonu bulunuyor
  • Agent'lar API'lerin başlıca tüketicisi olarak öne çıkıyor; geliştiriciler kodlama agent'ları aracılığıyla uygulamalarını, agent'larını ve platformlarını Cloudflare üzerinde geliştirip dağıtıyor
  • Cloudflare, tüm API'lerini 1.000 token'dan küçük tek bir Code Mode MCP sunucusu üzerinden sunuyor; ancak CLI komutları, Workers binding'leri, SDK'ler, yapılandırma dosyaları, Terraform, geliştirici dokümantasyonu ve Agent Skills gibi daha fazla arayüzün kapsanması gerekiyor
  • Mevcut Wrangler CLI içinde birçok Cloudflare ürününe ait CLI komutu eksikti ve agent'lar CLI'ı tercih etme eğiliminde

Yeni nesil Wrangler CLI'nin yeniden inşası

  • Wrangler CLI, Cloudflare'in tamamı için bir CLI olacak şekilde yeniden inşa ediliyor; böylece tüm ürünler için komutlar sağlanacak ve infrastructure-as-code yaklaşımıyla birleşik yapılandırma mümkün olacak
  • Teknik önizleme npx cf veya npm install -g cf ile kurulabiliyor
  • Şu anda yalnızca bazı ürünler destekleniyor, ancak şirket içinde Cloudflare'in tüm API yüzeyini destekleyen bir sürüm test ediliyor
  • Her ürüne ait komutlar, hem agent'lar hem de insanlar için ergonomik çıktı sağlayacak şekilde gözden geçirilip ayarlanıyor
  • Önümüzdeki aylarda bunun mevcut Wrangler'ın güçlü yönleriyle birleştirilmesi planlanıyor

TypeScript tabanlı şema ve kod üretim hattı

  • Daha önce OpenAPI şemaları temel alınarak API SDK'leri, Terraform provider'ı ve Code Mode MCP sunucusu otomatik olarak üretiliyordu
  • CLI, Workers binding'leri, wrangler.jsonc yapılandırması, Agent Skills, dashboard ve dokümantasyon güncellemeleri ise hâlâ manuel süreçlerle yürütülüyordu; bu da sık hatalara ve ölçeklenebilirlik sorunlarına yol açıyordu
  • OpenAPI şemaları yalnızca REST API'leri tanımlayabildiği için, yerel geliştirme ile API isteklerini birleştiren etkileşimli CLI komutları, RPC tabanlı Workers binding'leri, ayrıca Agent Skills ve dokümantasyonu ifade etmekte yetersiz kalıyordu
  • Cloudflare, TypeScript'in şirket içinde ortak dil olarak kullanılmasından hareketle; Cap n' Web, Code Mode ve Workers platformunun RPC sistemi gibi alanlarda TypeScript ile API ifade etmenin daha etkili olduğunu gördü
  • Yeni TypeScript şeması, API'leri, CLI komutlarını ve argümanlarını, ayrıca arayüz üretimi için gereken tüm bağlamı tanımlıyor
    • TypeScript tiplerine konvansiyonlar, linting ve koruma mekanizmaları uygulanmış bir yapı
    • Kendi biçimi olduğu için ihtiyaç duyulan her türlü arayüzü esnek biçimde desteklerken OpenAPI şeması üretimi de mümkün

Agent'lar ve CLI için tutarlılık ile bağlam mühendisliği

  • Agent'lar CLI'da tutarlılık bekliyor; bir komut info, diğeri get kullanırsa agent'lar var olmayan komutları çağırabiliyor
  • Yüzlerce ya da binlerce mühendisin bulunduğu büyük organizasyonlarda yalnızca code review ile tutarlılığı korumak, İsviçre peyniri modeli gibi kaçınılmaz boşluklar oluşturuyor
  • Tutarlılığı yalnızca CLI katmanında zorunlu kılmak, CLI, REST API ve SDK arasında adlandırma farklarını daha da kötüleştirebiliyor
  • Kurallar ve koruma mekanizmaları şema düzeyinde uygulanıyor: her zaman get (asla info değil), her zaman --force (asla --skip-confirmations değil), her zaman --json (asla --format değil) gibi kurallar tüm komutlarda tutarlı biçimde destekleniyor
  • Wrangler CLI, hem yerel olarak simüle edilen kaynaklar hem de uzak kaynaklar üzerinde çalışan özel bir yapıya sahip
    • D1 veritabanı, R2 depolama bucket'ı ve KV namespace'i gibi kaynaklar hem yerel hem uzak kullanım sunuyor
    • Agent'ın uzak veritabanını değiştirdiğini sanırken gerçekte yerel veritabanına kayıt eklemesi gibi karışıklıklar yaşanabiliyor
    • Tutarlı varsayılanlar ve çıktıda bunun yerel mi uzak mı olduğunu açıkça gösteren bilgilerle agent'lara net yönlendirme sağlanıyor

Local Explorer — yerelde de uzaktakiyle aynı kaynak keşfi

  • Local Explorer açık beta olarak yayımlandı ve hem Wrangler CLI hem de Cloudflare Vite eklentisi içinde kullanılabiliyor
  • Yerel geliştirme sırasında Worker'ın kullandığı simüle edilmiş kaynaklar doğrudan incelenebiliyor: KV, R2, D1, Durable Objects, Workflows
  • Cloudflare API'si ve dashboard üzerinden yapılabilen işlemlerin aynısı, tamamen yerel ortamda ve aynı API yapısıyla gerçekleştirilebiliyor
  • Cloudflare yıllardır tam yerel geliştirmeye yatırım yapıyor; D1 gibi barındırılan sunucusuz veritabanları bile ek yapılandırma veya araç gerektirmeden binding'ler üzerinden tamamen yerelde çalışabiliyor
    • Miniflare (yerel geliştirme platformu emülatörü), prodüksiyonla aynı API'yi sunuyor ve yerel SQLite veritabanı kullanıyor
    • Ağ erişimi olmadan hızlıca test yazıp çalıştırmak mümkün ve sistem çevrimdışı da çalışabiliyor
  • Daha önce yerelde hangi verilerin tutulduğunu görmek için .wrangler/state dizinini tersine mühendislikle çözümlemek ya da üçüncü taraf araçlar kurmak gerekiyordu
  • Uygulama Wrangler CLI veya Cloudflare Vite eklentisiyle çalıştırıldığında, Local Explorer'ı açma istemi gösteriliyor ve e klavye kısayoluyla erişilebiliyor
    • Mevcut Worker'a bağlı binding'leri ve bunların verilerini görebileceğiniz bir yerel arayüz sunuluyor
  • Agent ile geliştirme yapılırken, agent'ın verileri nasıl ele aldığını anlamakta faydalı; ayrıca şema doğrulama, test kaydı seed etme ve DROP TABLE ile sıfırlama da yapılabiliyor
  • Yalnızca yerel verileri değiştiren bir Cloudflare API aynası sunularak, yerel kaynaklara uzaktakiyle aynı API üzerinden erişim sağlanıyor
    • Yerel ve uzak API biçimi aynı olduğundan, CLI'da --local bayrağı verildiğinde istek yerel ayna API'sine yönlendirilerek aynı şekilde çalışıyor
  • Yerel API'ye /cdn-cgi/explorer/api yolundan erişilebiliyor; agent'lar bu adres üzerinden OpenAPI spesifikasyonunu keşfedip yerel kaynakları yönetebiliyor

Geri bildirim çağrısı ve sonraki planlar

  • Yeni nesil CLI teknik önizlemesi npx cf veya npm install -g cf ile kullanılabiliyor
  • Cloudflare, yalnızca mevcut teknik önizleme özellikleri için değil, tüm platformu kapsayan bir CLI'dan ne beklendiğine dair de geri bildirim istiyor
    • Dashboard'da birçok kez tıklama gerektiren ama tek satırlık bir CLI komutuyla yapılması istenen işler
    • wrangler.jsonc içinde yapılandırmak istediğiniz öğeler (ör. DNS kayıtları, cache kuralları)
    • Agent'ların takıldığı noktalar ve CLI'da bulunması istenen komutlar
  • Geri bildirimler Cloudflare Developers Discord üzerinden toplanıyor

İlgili okumalar

2 yorum

 
eoeoe 15 일 전

FTS tablosu yapılandırılmış bir D1 veritabanını dışa aktarmayı denerken ortaya çıkan hatayı da birlikte düzeltseler iyi olur.
wrangler kullanırken en rahatsız edici şey bu.
 
GN⁺ 16 일 전
Hacker News görüşleri

  • Wrangler CLI'nin yerel geliştirme sırasında gereken API token izinlerini önceden göstermesi iyi olurdu
    Böylece dağıtımdan önce hangi izinlerin gerektiği net biçimde görülebilir; ayrıca cf permissions check gibi bir komutla eksik ya da gereksiz izinler denetlenebilse ideal olurdu

    • Kesinlikle katılıyorum. ChatGPT başta izinleri yanlış ayarladığında, sonunda saatlerce belgeleri karıştırmak ya da token kombinasyonlarını denemek gerekiyor
    • Böyle bir işi yapan bir doctor komutu olsa gerçekten çok kullanışlı olurdu. Keşke daha fazla servis bunu sunsa
    • Eskiden bir yazım hatası yüzünden token'ı yanlış ayarlamıştım; böyle bir özellik olsaydı çok yardımcı olurdu
    • Bir adım öteye gidersek, CLI'nin anahtarları otomatik oluşturması da güzel olabilir
    • Sonuçta asıl mesele API'nin keşfedilebilirliğini (discoverability) artırmak diye düşünüyorum
      GraphQL, HATEOAS ilkelerini iyi izlediği için LLM'lerin API'yi keşfetmesi açısından avantajlı
      Belge sürümlerinin uyuşmamasından doğan sorunlardan ziyade, API'nin kendi işlevlerini kendisinin açığa vurduğu bir yapı çok daha iyi bence

  • Önce kaynak grubu düzeyinde yetki kontrolü eklenmesini isterdim
    Şu anda sadece zone (alan adı) tabanlı izinler var; bu yüzden zone'a bağlı olmayan worker gibi kaynaklarda, düşük yetkilerle bile kod değiştirilebiliyor ya da silinebiliyor
    GitHub Enterprise gibi bir super account + sub account yapısı desteklense daha da iyi olurdu. Örn: ACME Corp / ACME Corp (Prod)

    • Acaba bu, Cloudflare Organization özelliğiyle aynı kavram mı diye merak ediyorum
    • Alan adları paylaşılamasa bile super account + sub account yapısı gerçekten çok faydalı olurdu
    • Worker'ların zone tabanlı olmaması nedeniyle işe yararlılığının düştüğü görüşüne katılıyorum

  • Harika bir yazıydı, ilham vericiydi. Ama TypeSpec'ten hiç söz edilmemesi şaşırtıcı
    TypeScript tarzı bir şema dili; genelde bunu “OpenAPI gerçekten iyi tasarlansaydı böyle görünürdü” diye anlatıyorum
    Muhtemelen kendi uygulamalarının daha basit ve esnek olduğuna karar vermişlerdir. Bugünlerde agent sayesinde BYO maliyeti de epey azaldı

    • TypeSpec'i gerçekten seviyorum. OpenAPI yazmayı çok daha kolay hale getiriyor
      Ama bu günlerde aep.dev tarzı API'leri tercih ediyorum. Tutarlı kalıplar sayesinde aepcli'yi doğrudan kullanmak ya da kendin yazmak kolay oluyor
      Terraform da ayrı bir provider olmadan doğrudan çalışıyor
    • OpenAPI'nin hangi yönlerini iyileştirdiğini merak ediyorum

  • Son dönemde yapay zeka agent odaklı CLI-first tasarımı ilginç geliyor
    Biz de geliştirici araçları üretirken önce CLI ve API'yi yaptık, dashboard'u sonradan ekledik
    Yukarıda bahsedilen cf permissions check fikrini özellikle beğendim
    Agent'lar CLI kullanmakta iyi ama hatanın nedenini teşhis etmede zayıf.
    “scope X eksik, cf token add --scope X çalıştırın” gibi açık hata mesajları çok daha önemli

  • Teknik önizlemenin npx cf ile hemen denenebildiği söyleniyor; ama birkaç sorum var
    Açık kaynak mı, ayrıca Node.js olmadan tek bir binary olarak sunulması planlanıyor mu öğrenmek isterim.
    Yakın zamanda satın alınan Bun gibi bir şey de kullanılabilir mi acaba?

    • Ben de repoyu bulamadım ama npm paketi MIT lisanslı ve içinde source map'ler var; yakında açılacak gibi görünüyor

  • Uzun ömürlü tokenlardan kaçınılmasını isterdim.
    Bunun yerine CLI içinde kısa ömürlü, kısıtlı tokenlar kolayca üretilebilmeli; bunlar dosya olarak yönetilebilmeli ya da otomatik yenilenebilmeli
    Bir başka seçenek olarak proxy modu eklenebilir; böylece yalnızca belirli alan adlarına ya da bucket'lara erişim yetkisi devredilebilir

    • GitLab'deki gibi SSH sunucusu üzerinden kısa ömürlü PAT tek seferde üretme yaklaşımını seviyorum

  • İronik biçimde, yapay zeka agent çağı geldikçe tekrar CLI merkezli geliştirmeye dönüyoruz
    Cloudflare önbelleğini her temizleyişimde web arayüzünde birden fazla adıma tıklamam gerekiyor; oysa sadece OpenClaw agent'a komut verebilmek isterdim

    • OpenClaw kullanmak şart değil. CLI komutunu doğrudan çağırmak yeterli. Zaten CLI'nin özü bu

  • Wrangler'ın kimlik doğrulama yöntemi yalnızca iki seçenek sunuyor: OAuth (tam yetki) ve dashboard'da elle oluşturulan statik tokenlar
    Ama insanlar ile yapay zeka agent'larının farklı yetki sınırlarına sahip olması gereken senaryolarda bu yeterli değil
    CLI içinden doğrudan scoped, short-lived tokenlar oluşturulabilse iyi olurdu
    Bu konu GitHub issue #13042'de de tartışılıyor.
    Tokenlar yalnızca kaynak türüne göre değil, kaynak ID'si ve eylem düzeyinde de ayrıntılı olmalı

  • Cloudflare, 1 Nisan'da EmDash'i x402 desteğiyle tanıtmıştı; şimdi ise odağı CLI'ye kaydırıyor gibi görünüyor
    Sanki Cloudflare, insan olmayan agent'ları ana kullanıcı kabul eden bir geliştirici ekosistemini sessizce yeniden kuruyor

  • API, CLI komutları, argümanlar ve context'in TypeScript şemalarıyla tanımlandığı söyleniyor;
    peki neden bu araç ya da framework burada tanıtılmadı diye merak ediyorum
    Acaba yukarıda sözü edilen TypeSpec ile benzer bir yapı mı?