Deno Kuyrukları

 (deno.com)
1 puan yazan GN⁺ 2023-09-29 | 1 yorum | WhatsApp'ta paylaş
  • Deno Queues, Deno KV üzerinde çalışan sunucusuz dağıtık kuyruk yapısıdır; uzun süren işleri asenkron olarak devretmeyi veya gelecekte çalışacak görevleri zamanlamayı mümkün kılar
  • Geliştiriciler mesajları .enqueue() ile kuyruğa ekleyip .listenQueue() ile işleyebilir; ayrıca ayrı bir kuyruk altyapısı kurup sürdürmeleri gerekmez
  • Yerelde SQLite, Deno Deploy üzerinde ise FoundationDB kullanır; Deploy, mesajın işleneceği anda V8 isolate'ı isteğe bağlı olarak başlatıp çalıştırır
  • Teslim modeli at-least-once delivery olduğundan, hata veya yeniden deneme durumlarında aynı mesaj birden fazla kez işlenebilir
  • Ayrı bir kuyruk ücreti yoktur; ancak enqueue işlemleri KV yazımı, mesaj alımı ise KV yazımı ve Deno Deploy isteği olarak hesaplandığından, yinelenen işleme ve maliyet yapısının birlikte değerlendirilmesi gerekir

Deno Queues ne işe yarar

  • Deno Queues, Deno KV tabanlı bir kuyruk özelliğidir; uygulamanın bazı işlemlerini asenkron işler olarak devretmeye veya daha sonra çalışacak işleri zamanlamaya olanak tanır
  • Deno, bulut yazılım geliştirmede tekrarlayan kurulum ve altyapı yapılandırmalarını azaltmayı, geliştiricilere daha hızlı tasarlama, iyileştirme ve yayına alma imkânı veren temel bileşenler sunmayı hedefler
  • Deno KV, FoundationDB tabanlı bir kalıcılık seçeneğidir ve şu anda açık beta durumundadır
  • Queues, Deno KV üzerinde ölçeklenebilir mesajlaşma ve arka plan işleme yönetimi sağlar

Temel API ve çalışma şekli

  • Deno Queues'in iki temel API'si vardır
    • .enqueue(): Yeni bir mesajı kuyruğa koyar ve hemen ya da gelecekte bir zamanda teslim edilmesini sağlar
    • .listenQueue(): Kuyruktan yeni mesajları alıp işleyen bir handler olarak kullanılır
  • Temel akış, Deno.openKv() ile KV'yi açmak, listenQueue içinde Slack mesajı göndermek ve enqueue içinde { delay: 60000 } belirterek işlemenin 60 saniye sonra yapılmasını sağlamaktır
  • Çalışma ortamına göre depolama katmanı değişir
    • Yerelde çalışırken SQLite kullanılır
    • Deno Deploy üzerinde çalışırken FoundationDB kullanılır
  • Deno Deploy, mesajın işlenebileceği zamanda V8 isolate'ı isteğe bağlı olarak çalıştırır ve mesajı dispatch eder
  • Uygulama kodunun yalnızca listenQueue handler'ı ile yeni mesajları alması yeterlidir; geri kalan yürütmeyi Deno Deploy üstlenir

Teslim garantisi ve yeniden denemeler

  • Deno Queues, at-least-once delivery garantisi verir
  • Çoğu enqueue edilen mesaj listenQueue handler'ını yalnızca bir kez çağırır; ancak bazı hata durumlarında teslim garantisini korumak için aynı handler birden fazla kez çağrılabilir
  • Bu nedenle uygulama, yinelenen mesaj işleme durumunu güvenli şekilde ele almalıdır
  • listenQueue handler'ı bir istisna fırlatırsa runtime çağrıyı otomatik olarak yeniden dener
  • Yeniden denemeler başarılı olana ya da azami yeniden deneme sayısına ulaşılana kadar sürer; şu anki varsayılan üst sınır 5 kezdir
  • Azami yeniden deneme sayısına ulaşan mesaj silinir

KV atomic transaction ile birlikte kullanma

  • Deno Queues, KV atomic transactions ile birleştirilebilir
  • Bir mesaj KV transaction'ının parçası olarak enqueue edilirse, mesaj yalnızca tüm transaction başarılı olduğunda kuyruğa girer
  • Örnek akışta Bob ve Liz'in bakiyesi kontrol edilip güncellenir, ardından her ikisine de bildirim mesajları enqueue edilir
    • check(bob, liz) ile durum kontrol edilir
    • Bob'un bakiyesi azaltılır, Liz'in bakiyesi artırılır
    • enqueue ile Liz ve Bob'a ayrı ayrı bildirim mesajları eklenir
    • Tüm değişikliklerin ve enqueue işlemlerinin uygulanması için commit() başarılı olmalıdır
  • Deno KV durumu listenQueue handler'ı içinde de güncellenebilir
  • Mesaj başına güncellemeyi yalnızca bir kez yapmak için nonce saklayıp silme yöntemiyle yinelenen işleme önleme akışı kurulabilir
    • Enqueue sırasında nonce da birlikte saklanır
    • İşleme sırasında nonce yoksa doğrudan geri dönülür
    • İşleme başarılı olduğunda nonce silinir ve sayaç ile bakiye durumu birlikte güncellenir

Kuyruğa uygun kullanım senaryoları

  • Kuyruklar, sunucunun asenkron işlemleri devretmesini ve gelecekteki işleri zamanlamasını sağlayarak uygulamayı ölçeklendirmede faydalıdır

  • Zamanlanmış e-posta bildirimleri

    • Kullanıcının başlattığı bir iş uzun sürüyorsa veya tamamlanma yanıtını beklemek gerekmiyorsa, işi kuyruğa devrederek sunucunun ya da uygulamanın yanıt verebilirliğini korumak mümkündür
    • Örnekte welcome_email mesajı hemen enqueue edilirken, survey_email mesajı { delay: 259200000 } ile gecikmeli çalıştırılır

  • Güvenilir webhook işleme

    • Webhook isteklerini anında işlemek yerine kuyruğa almak, yanıt ile gerçek işlemenin ayrılmasını sağlar
    • Oak ve Queues birlikte kullanılarak /webhook POST isteği alındığında istek gövdesi kuyruğa konur ve HTTP 200 döndürülür
    • Gerçek webhook işleme listenQueue içinde processWebHook ile asenkron olarak yapılır

  • Slack·Discord botları

    • Queues, Discord veya Slack botları oluşturmak için de kullanılabilir
    • Slack reminder app örneği, Deno Queues ile basit bir Slack hatırlatıcı uygulaması yapımını gösterir
    • Discord bot örneği, Deno Queues ile bir giveaway oluşturup kullanıcıların tek tıklamayla katılmasını sağlar
    • Daha fazla kuyruk kullanım örneği için docs.deno.com incelenebilir

Fiyatlandırma modeli

  • Deno Queues için ayrı, özel bir ücretlendirme kalemi yoktur
  • Maliyetler Deno KV işlemleri ve Deno Deploy istekleri üzerinden hesaplanır
    • Mesaj enqueue: Her enqueue işlemi 1 KV yazma işlemine karşılık gelir
    • Mesaj alımı: Alınan her mesaj için 1 KV yazma işlemi ve 1 istek ücreti oluşur
  • Yalnızca kullanılan işlemler kadar ücretlendirme yapılır

Belgeler ve yol haritası

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-29
Hacker News görüşleri

  • Az önce yerel SQLite sürümünün içini kurcalayıp notlarımı derledim: https://til.simonwillison.net/deno/deno-kv#user-content-deno...
    En ilginç kısım muhtemelen bu özellik için kullanılan şema:
    CREATE TABLE queue ( ts integer not null, id text not null, data blob not null, backoff_schedule text not null, keys_if_undelivered blob not null, primary key (ts, id) );
    CREATE TABLE queue_running( deadline integer not null, id text not null, data blob not null, backoff_schedule text not null, keys_if_undelivered blob not null, primary key (deadline, id) );
    CREATE INDEX kv_expiration_ms_idx on kv (expiration_ms);

    • Neredeyse aynı alanlara sahip 2 tablo oluşturup satırları taşımak genelde kötü bir pratik değil mi diye düşünüyorum
      İndeksler tam da bu tür amaçlar için tasarlanmamış mı?
    • “Açık kaynak iş modeli” açısından özellikle ilginç olan nokta, Deno’nun framework’ün çekirdek işlevlerine, küresel ölçekte bir yükseltme olarak yalnızca kendi SaaS platformunun iyi sunabileceği özellikler ekliyor olması
      Oldukça yeni ama biraz da tedirgin edici. Elbette ticarileşmeleri gerekiyor, ancak bunun tamamen kapalı bir şekilde olması şart değildi; ölçeklendirme katmanı için BSL veya PolyForm gibi başka lisanslar da kullanılabilirdi

  • Deno’nun burada hedeflediği yönün oldukça geleceğe dönük olduğunu düşünüyorum
    Bu yıl ilk kez Go kullanıyorum ve dilin bazı kısımları C’ye çok benziyor. C’den farklı olan şeylerin, örneğin garbage collection sayesinde fonksiyonlardan stack’te ayrılmış pointer’lara benzeyen değerler döndürebilmenin yanı sıra, map[string]string gibi yerleşik özellikler de doğal şekilde dilin içinde yer alıyor. 2023’ten sonra yeni bir dil yapıyorsanız map türlerini ele alan yerleşik sözdiziminin olmaması neredeyse akıl almaz geliyor
    Bu yüzden web sunucusu merkezli bir ekosistemin, sık kullandığımız temel yetenekler için kütüphanelere, belki bir gün dil sözdizimine bile sahip olması mantıklı görünüyor. Dağıtık bir web sunucusunda cache için key-value store, kilitleme mekanizması, hatta geçici queue bile olmayan son projemi hatırlamıyorum. Key-value store’suz dağıtık sistem, map türü olmayan bir programlama diline belli belirsiz benziyor; gerçekten İsviçre çakısı gibi bir teknoloji
    Olası sorun, Deno’nun bu yolda tek başına ilerlemesi. Deno’nun şu anda eklediği yeni özelliklerin rakip platformlarda da sunulup sunulmayacağından emin olmak zor; API’yi açık kaynak yayımlasa bile Deno namespace’i içinde olduğundan, AWS’te FoundationDB yerine Redis’e geçmek istediğinizde bunun doğrudan çalışıp çalışmayacağını bilmiyorum
    Bu yüzden Deno’dan kaçınmak istiyorum gibi hissediyorum. Sözdizimi ve sunduğu özellikler gerçekten çekici, ama bağımlı olduktan sonra kodu çeşitli bulut altyapılarına dağıtılabilir hâle getirmek için büyük ameliyatlar yapmak zorunda kalır mıyım diye kaygılanıyorum. Birçok müşteri bunu talep ediyor. Örneğin bir gün Oracle’a ya da Salesforce’a satış yapmak isteyip onlar on-premise çalıştırma isterse, onların kullanabildiği key-value store’u Deno paket özelliğine nasıl uyduracağım benim üzerime kalıyor
    İki ucu keskin bir kılıç. Deno bu vizyonu daha geniş kitlelere kabul ettirmeyi başarabilir, ama bir süre temkinli bakacağım gibi görünüyor

    • Bu durumda uzak bağlantı protokolü olan KV Connect de belgelenmiş: https://github.com/denoland/deno/tree/main/ext/kv#kv-connect
      Bu protokolü saf TypeScript ile uygulayan kv-connect-kiti biraz denedim; herhangi bir JavaScript runtime’ında KV client API’si sağlıyor. Deno namespace’i hiç olmayan Cloudflare Workers da buna dahil
      GitHub: https://github.com/skymethod/kv-connect-kit / npm: https://www.npmjs.com/package/kv-connect-kit / deno/x: https://deno.land/x/kv_connect_kit / demo: https://keyspace.deno.dev/
      Protokol anlatıldığı gibi çalışıyor gibi görünüyor ve başka backend’ler yazmak da epey basit görünüyor
    • Katılmıyorum. Dil runtime’ını belirli bir hosting servisine bağlı belirli bir KV arayüzü ile birleştirmek, geleceğe dönük olmanın tam tersi
      Teknoloji sektörü vendor lock-in stack’lerinden uzaklaşmak için epey yol katetti; bu ise aksine o dönemleri hatırlatıyor
      Deno.KV’nin runtime’ın bir parçası olmasıyla dosyanın en üstüne import KV eklemek arasında pratikte ne fark var, bilmiyorum. İkincisini Deno’dan da istediğiniz başka bir yerden de içe aktarabilirsiniz
      Ayrıca Deno ekibinin kendi dili dışında başka diller için binding sağlama olasılığı ne kadar? Google, Go’ya Google Cloud’a özel ilkel özellikleri native olarak eklemeye başlasa buna geleceğe dönük mü diyeceğiz?
    • Deno’yu seviyorum ama aynı nedenle benimsemekte temkinli davranıyorum. Deno’nun kazanması için hosting rakiplerini de tamamen desteklemesi gerekecek gibi
      Aynı zamanda kendi hosting’i de sektör liderleriyle aynı seviyede ya da daha iyi olmalı. Başka bir yol olarak kendi hosting’inden vazgeçip, hosting iş ortaklarının adaptörleri üzerine ince bir marj koyan multi-cloud bir çözüm sunabilir. Böylece Deno’nun doğrudan hosting sağlayıcısı olarak rekabet etmesi gerekmez
    • Deno bununla yalnızca diğer JS/TS SaaS’larla rekabet etmeye çalışıyor. Vercel/NextJS’in de KV servisi var, Cloudflare’ın da var; başka durumlarda Firebase var
      Bence bu geleceğe dönük olmaktan çok Deno’yu SaaS olarak paraya çevirmekle ilgili. Bugün JavaScript dünyasında herkesin “bulut” ürünüyle yaptığı şey; yani bir framework iliştirip AWS’i yeniden satma akımı. Bu yüzden üzerinde fiyat etiketi var
      Deno’nun KV’si FoundationDB’ye dayanıyorsa başka veritabanları için aktif şekilde adaptör geliştirmeleri de düşük olasılık gibi görünüyor. Veritabanı teknolojisini değiştirmek her zaman büyük iştir; çünkü her birinin kullanım amacı ve performans özellikleri farklıdır
    • GC allowing one to return what look like stack allocated pointers from functions bunun garbage collection’dan çok escape analysis ve SSA sayesinde olduğunu düşünüyorum

  • “Genel bulut altyapısından yararlanmak için boilerplate kod ve karmaşık ayarların içinde kaybolmak gerekiyor; bu da geliştiricinin zamanını ve enerjisini çok tüketiyor” argümanı bana pek ikna edici gelmiyor
    Sonuçta kararlı olması gereken bir altyapı inşa ediyoruz. Kanıtlanmış bir teknoloji olan SQS kuyruğunu yapılandırmaya 30 dakika harcamak, Deno’nun “SQLite / FoundationDB üzerine” yaptığı oyuncak bir kuyruğa tamamen güvenmekten daha kötü görünmüyor. 30 dakikalık yapılandırma maliyeti ve iyileşmiş “geliştirici deneyimi” gerçekten bu riski almaya değer mi? Zaten kuyrukları ne kadar sık yapılandırıyoruz ki?

    • Bunun nasıl biri olduğuma göre değiştiğini düşünüyorum
      Hobi amaçlı programcı olarak AWS veya Google gibi büyük sağlayıcıları pek kullanmıyorum; çünkü oldukça karmaşık görünüyorlar. Alışkınsanız o kadar kötü olmayabilir
      Ayrıca her projeyi GitHub’da bağımsız bir depo olarak tutmak istiyorum. İdeal olarak bir web uygulamasını başka herhangi biri, ayrı bir alan adında kendi bağımsız web uygulamasıymış gibi kolayca ayağa kaldırabilmeli. Çünkü başkalarının verilerinin sorumluluğunu da almak istemiyorum
      Bu, bir ölçüde Sandstorm kullanım senaryosuna benziyor. “Yerelde deneyin, gerçekten kullanmak için Deno Deploy hesabı oluşturun” şeklindeki kurulum yönergesi kulağa epey makul geliyor
    • Pek çok kişinin AWS veya SQS deneyimi yok; deneyimi olanların bile hâlâ bunlarla ilgilenmesi gerekiyor. Deno, geliştiricinin bir şeyi alıp hemen kullanabilmesi için piller dahil yaklaşımını seçiyor
      Birisi bulut için eşdeğer bir kütüphane sağlarsa, bunu benimseyecek insanlar kesinlikle olacaktır. Deno’nun durumunda, kendi ekosistemindeki geliştiricilerin yaşadığı ortak sorunları tespit edip makul bir çözümü paketleyerek çözmeye çalışıyor gibi görünüyor
    • Sert konuşacak olursam, artık kuyrukları doğrudan kullanmamak daha iyi bence. Ham HTTP/2 kullanmaya veya thread’leri doğrudan yönetmeye benziyor
      Kuyruğu soyutlayan bir iş akışı motoru kullanırsanız işleri, zamanlamaları, durumu ve yeniden denemeleri yönetmeden “sadece kod yazmak” mümkün olur
      https://www.inngest.com/blog/how-durable-workflow-engines-wo...
      Ancak ben bir iş akışı motoru yazarıyım, dolayısıyla önyargılıyım
    • Bu mantığa göre yeni çıkan her şey temelde “oyuncak proje” olur; yalnızca AWS doğrulanmış sayıldığı için kimse yeni ürün çıkarmamalı demektir
    • Bunun oyuncak bir kuyruk olduğunu nereden biliyorsun?

  • “En az bir kez teslim semantiği” ve “kullanıcı kodu” ile ilgili eski deneyimlerime göre, kullanıcılar en az bir kez teslimi doğru anlamıyor
    Mesajı yeniden teslim ettiğiniz anda kullanıcı şikâyetleri ve arızalar yağmaya başlıyor
    Neredeyse imkânsız olanı başarıp tam olarak bir kez teslim semantiğini icat etmek ya da kullanıcıların tek sefer teslim edildiğine güvenememesi için tüm mesajların %0,1’ini her zaman yeniden teslim etmek gerektiğini düşünüyorum

    • İlk SQS fiilen böyleydi. Kasıtlı mıydı bilmiyorum ama bu sayede yeniden teslimlere saygı göstermek gerektiğini çabuk öğrendim
    • Mesajların idempotent olması gerekiyorsa, gönderici tarafta bunu garanti eden entegrasyon testleri oluşturmanızı kesinlikle öneririm

  • Şu anda Deno Deploy kullanıyorum; tek başıma yaptığım projeler açısından performansı harika ve gerçekten basit
    Büyük ekiplerde AWS geliştirmesi yapmış biri olarak, ayarları düşünmeden kolayca ayağa kaldırmayı sağlayan ve karmaşıklıktan uzaklaşan bu akımı görmek sevindirici. DNS de çok basitti, otomatik SSL sertifikası da gerçekten güzeldi. Bu ürünün hedeflediği şey konusunda hiç şikâyetim yok ve yol haritasını da merakla bekliyorum

  • Gözden kaçırmadıysam, her Deno.openKv() örneğinde yalnızca tek bir kuyruk var gibi görünüyor
    Yerel sürümde her seferinde farklı bir SQLite dosya yolu ile Deno.openKv("db-2.db") çağırarak birden fazla kuyruk oluşturabilirsiniz; ama oldukça yaygın bir ihtiyaç için ek yükü fazla görünüyor
    Belki de bu Deno’nun mimari tarzıdır. Deno ile karmaşık uygulamalar geliştirirken birden fazla script’in birlikte çalıştığı, her birinin kendi KV deposu ve kuyruğu olan mikroservis tarzı bir yapı mı bekleniyor?

  • Fiyatlandırma nasıl?
    Deno’yu bir tür Node.js alternatifi sanıyordum; bir şeyi mi kaçırıyorum? Bunu yerelde veya self-hosting ile ücretsiz kullanabiliyor muyum?

    • Bu, Deno KV’nin geri kalanıyla aynı şekilde çalışıyor. Açık kaynak sürüm SQLite kullanıyor; ama Deno’nun bulut ürününe dağıttığınızda bunun yerine tescilli FoundationDB kullanılıyor
      Açıklama şu: “Queues are built on Deno KV”; yani yerelde SQLite kullanıyor, Deno Deploy’da ise maksimum erişilebilirlik ve iş hacmi için FoundationDB kullanıyor
      Bu desen hakkında burada biraz daha yazdım: https://til.simonwillison.net/deno/deno-kv
    • Yazıya göre geliştirme sırasında yerelde SQLite kullanıyor; Deno’ya dağıttığınızda ise bulutun sunduğu işlevlerin bir parçası oluyor

  • Geliştiriciler görüyorsa, mevcut harika KV kullanılabilirliğinde erişim kontrolü tarafının ileride acı yaratacağını düşünüyorum
    Çözümün sadece “kullanıcı alanında kendiniz uygulayın ve hata yapmayın” mı olduğunu, yoksa planlanan bir şey olup olmadığını merak ediyorum

    • Kullanıcı düzeyinde erişim kontrolünden mi söz ediyorsunuz; örneğin kimliği doğrulanmış kullanıcılar için ACL gibi bir şeyden mi, yoksa başka bir şeyden mi? Daha uzun düşüncelerinizi paylaşırsanız bu endişeyi akılda tutmaya devam ederim

  • Son dönemdeki Jupyter desteği ve bu kuyruk özelliği heyecan verici. Gerçekten harika şeyler
    Ama Deno ile sunucu yazıp kendi sunucumda production’a alacağımı sanmıyorum. Serverless’ı sevmiyorum
    Deno ve Bun’ın iş modeli serverless, yani Deno Deploy etrafında kurulmuş durumda. Deno Deploy da başka bir runtime
    KV ve kuyruklarda bu açıkça görülüyor. Yerelde veya self-hosting’de başka teknolojilerin üzerine konmuş, zar zor çalışan bir sürüme sahip oluyorsunuz
    Yani Deno müşterilerinin çoğunun kullandığından farklı bir Deno sürümünü self-host etmiş oluyorsunuz
    Kendi donanımında sunucu çalıştırmak için Deno kullanan kaç kişi var ki? Bu sayı azsa ben Node kullanmayı tercih ederim

  • Deno gerçekten ilginç. Uygulanabilir bir iş modeli, iyi kullanılabilirlik ve gereksiz yapılandırma angaryalarının olmaması harika

    • Deno için umutlanmaya çalıştım ama emin değilim. Geçmişte sayısız kez yaptıklarımızdan ne farkı olduğunu göremiyorum
      Deno’nun kendisi özünde Node.js’e otomatik TypeScript derlemesi eklenmiş hâli. Normalde bunun için sadece bir yapılandırma dosyası daha gerekirdi. Proje çıktığında dağınık NPM ekosisteminden kurtulmayı büyük bir avantaj olarak öne çıkarıyordu, ama sonunda geri dönüp NPM desteği eklemek zorunda kaldı ve bu farklılaştırıcı nokta da ortadan kalktı
      Deno Deploy, hâlihazırda onlarcası bulunan Lambda türü servislerle aynı. KV depolama ve şimdi de kuyruk; Redis, LevelDB, RocksDB, Dynamo, SQS veya sayısız benzer seçenekle eşdeğer. Deno’yu diğerlerinden gerçekten ayıran tek bir özellik bile hâlâ görmüş değilim
      Dil çalışma zamanı, compute hosting ve veri deposunu tek bir şirketin üstlenmesini tercih ediyorsanız çekici olabilir. Ama şahsen bundan kaçınmak isterim; özellikle de o şirketin bu alanda bir geçmiş başarısı yoksa
    • Deno’nun uygulanabilir bir iş modeli olduğuna inanmanızın nedeni ne?