Deno Queues

 (deno.com)
1 poin oleh GN⁺ 2023-09-29 | 1 komentar | Bagikan ke WhatsApp
  • Deno Queues adalah antrean terdistribusi serverless yang dibangun di atas Deno KV, memungkinkan pekerjaan yang memakan waktu dialihkan secara asinkron atau dijadwalkan untuk dijalankan di masa mendatang
  • Developer cukup memasukkan pesan dengan .enqueue() dan memprosesnya dengan .listenQueue(), tanpa perlu menyiapkan atau memelihara infrastruktur antrean terpisah
  • Secara lokal menggunakan SQLite, sedangkan di Deno Deploy menggunakan FoundationDB; Deploy menjalankan V8 isolate secara on-demand saat pesan diproses
  • Mekanisme pengirimannya adalah at-least-once delivery, sehingga dalam kondisi kegagalan atau retry, pesan yang sama bisa diproses beberapa kali
  • Tidak ada biaya antrean terpisah, tetapi enqueue dihitung sebagai penulisan KV, sementara penerimaan pesan dihitung sebagai penulisan KV dan request Deno Deploy, sehingga pemrosesan duplikat dan struktur biaya perlu dipertimbangkan bersama

Tugas yang Ditangani Deno Queues

  • Deno Queues adalah fitur antrean berbasis Deno KV yang memungkinkan sebagian pemrosesan aplikasi dialihkan menjadi pekerjaan asinkron atau menjadwalkan pekerjaan untuk dijalankan nanti
  • Deno bertujuan mengurangi konfigurasi berulang dan penataan infrastruktur dalam pengembangan software cloud, serta menyediakan komponen dasar agar developer dapat merancang, memperbaiki, dan merilis lebih cepat
  • Deno KV adalah opsi persistensi berbasis FoundationDB, dan saat ini berstatus open beta
  • Queues menyediakan messaging yang dapat diskalakan dan pengelolaan pemrosesan background di atas Deno KV

API Dasar dan Cara Eksekusi

  • API inti Deno Queues terdiri dari dua hal
    • .enqueue(): memasukkan pesan baru ke antrean agar dikirim segera atau pada waktu mendatang
    • .listenQueue(): digunakan sebagai handler yang menerima dan memproses pesan baru dari antrean
  • Alur dasarnya adalah membuka KV dengan Deno.openKv(), mengirim pesan Slack di listenQueue, lalu menetapkan { delay: 60000 } pada enqueue agar diproses 60 detik kemudian
  • Penyimpanan berbeda tergantung lingkungan eksekusi
    • Saat dijalankan secara lokal, menggunakan SQLite
    • Saat dijalankan di Deno Deploy, menggunakan FoundationDB
  • Di Deno Deploy, saat pesan siap diproses, V8 isolate dijalankan secara on-demand dan pesan didispatch
  • Kode aplikasi cukup menerima pesan baru melalui handler listenQueue, sementara pengelolaan eksekusi lainnya ditangani oleh Deno Deploy

Jaminan Pengiriman dan Retry

  • Deno Queues menjamin at-least-once delivery
  • Sebagian besar pesan yang di-enqueue hanya memanggil handler listenQueue satu kali, tetapi dalam beberapa kondisi kegagalan, handler yang sama dapat dipanggil beberapa kali demi menjamin pengiriman
  • Karena itu, aplikasi harus menangani pemrosesan pesan duplikat dengan aman
  • Jika handler listenQueue melempar exception, runtime akan otomatis mencoba ulang pemanggilan tersebut
  • Retry berlanjut hingga berhasil atau mencapai jumlah maksimum retry; nilai maksimum default saat ini adalah 5 kali
  • Pesan yang mencapai jumlah maksimum retry akan dihapus

Digunakan Bersama KV atomic transaction

  • Deno Queues dapat digabungkan dengan KV atomic transactions
  • Jika pesan di-enqueue sebagai bagian dari transaksi KV, pesan hanya masuk ke antrean ketika seluruh transaksi berhasil
  • Contoh alurnya adalah memeriksa dan memperbarui saldo Bob dan Liz, lalu meng-enqueue pesan notifikasi untuk keduanya
    • Memeriksa status dengan check(bob, liz)
    • Mengurangi saldo Bob dan menambah saldo Liz
    • Menambahkan pesan notifikasi masing-masing untuk Liz dan Bob dengan enqueue
    • Seluruh perubahan dan enqueue baru diterapkan jika commit() berhasil
  • Status Deno KV juga dapat diperbarui di dalam handler listenQueue
  • Untuk memastikan update per pesan hanya dilakukan satu kali, alur pencegahan pemrosesan duplikat dapat dibuat dengan menyimpan dan menghapus nonce
    • Saat enqueue, simpan nonce bersama pesan
    • Saat pemrosesan, jika nonce tidak ada, langsung return
    • Saat pemrosesan berhasil, hapus nonce dan perbarui counter serta status saldo bersama-sama

Use Case yang Cocok untuk Antrean

  • Antrean berguna untuk memperluas aplikasi karena memungkinkan server mengalihkan pemrosesan asinkron dan menjadwalkan pekerjaan mendatang

  • Notifikasi Email Terjadwal

    • Ketika pekerjaan yang dimulai pengguna memakan waktu lama atau tidak perlu menunggu respons selesai, pekerjaan dapat dialihkan ke antrean agar responsivitas server atau aplikasi tetap terjaga
    • Dalam contoh, pesan welcome_email langsung di-enqueue, sedangkan pesan survey_email dijalankan tertunda dengan { delay: 259200000 }

  • Pemrosesan Webhook yang Andal

    • Dengan memasukkan request webhook ke antrean alih-alih langsung memprosesnya, respons dapat dipisahkan dari pemrosesan sebenarnya
    • Menggunakan Oak bersama Queues, ketika menerima request POST ke /webhook, body request dimasukkan ke antrean dan HTTP 200 dikembalikan
    • Pemrosesan webhook sebenarnya dilakukan secara asinkron di listenQueue melalui processWebHook

  • Bot Slack·Discord

    • Queues juga dapat digunakan untuk membangun bot Discord atau Slack
    • Contoh aplikasi Slack reminder adalah kasus pembuatan aplikasi reminder Slack sederhana dengan Deno Queues
    • Contoh bot Discord membuat giveaway dengan Deno Queues dan memungkinkan pengguna ikut serta dengan sekali klik
    • Contoh penggunaan antrean lainnya dapat dilihat di docs.deno.com

Model Biaya

  • Deno Queues tidak memiliki item biaya khusus yang terpisah
  • Biaya dihitung berdasarkan operasi Deno KV dan request Deno Deploy
    • Message enqueue: setiap operasi enqueue setara dengan 1 operasi penulisan KV
    • Penerimaan pesan: setiap pesan yang diterima menimbulkan 1 penulisan KV dan 1 biaya request
  • Strukturnya hanya menagih operasi yang digunakan

Dokumentasi dan Roadmap

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-29
Opini Hacker News

  • Baru saja membongkar bagian dalam versi SQLite lokal dan merapikan catatan: https://til.simonwillison.net/deno/deno-kv#user-content-deno...
    Bagian yang mungkin paling menarik adalah skema yang digunakan untuk fitur ini:
    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);

    • Membuat dua tabel dengan field yang hampir sama lalu memindahkan baris rasanya biasanya praktik yang buruk
      Bukankah indeks memang dirancang untuk kegunaan seperti itu?
    • Yang terutama menarik dari sudut pandang “model bisnis open source” adalah Deno memasukkan ke fitur inti framework kemampuan yang sebenarnya hanya bisa disediakan dengan baik sebagai upgrade skala global oleh platform SaaS mereka sendiri
      Ini cukup baru, tapi juga agak mengkhawatirkan. Tentu saja mereka perlu mengomersialkannya, tetapi tidak harus sepenuhnya tertutup; untuk lapisan perluasan, mereka mungkin bisa memakai lisensi lain seperti BSL atau PolyForm

  • Menurut saya, arah yang diincar Deno di sini cukup berorientasi masa depan
    Tahun ini saya baru pertama kali memakai Go, dan sebagian bahasanya sangat mirip dengan C. Selain hal-hal yang berbeda dari C, misalnya karena garbage collection kita bisa mengembalikan nilai dari fungsi yang tampak seperti pointer yang dialokasikan di stack, fitur bawaan seperti map[string]string juga terasa masuk secara alami. Jika membuat bahasa baru setelah 2023, rasanya hampir tidak masuk akal kalau tidak ada sintaks bawaan untuk menangani tipe map
    Jadi, menurut saya logis jika ekosistem yang berpusat pada web server memiliki library untuk kemampuan primitif yang sering kita pakai, bahkan mungkin suatu hari sampai menjadi sintaks bahasa. Saya tidak ingat proyek terakhir di web server terdistribusi yang tidak memiliki key-value store untuk cache, mekanisme locking, bahkan antrean sementara. Sistem terdistribusi tanpa key-value store samar-samar mirip dengan bahasa pemrograman tanpa tipe map, dan ini benar-benar teknologi seperti pisau Swiss Army
    Masalah potensialnya adalah Deno menempuh jalan ini sendirian. Sulit memastikan apakah fitur-fitur baru yang ditambahkan Deno saat ini juga akan tersedia di platform pesaing, dan meskipun API-nya dibuka sebagai open source, karena berada di namespace Deno, saya tidak tahu apakah semuanya akan langsung berjalan saat ingin mengganti FoundationDB dengan Redis di AWS
    Karena itu, saya merasa ingin menghindari Deno. Sintaks dan fitur yang dieksposnya memang sangat menarik, tetapi saya khawatir setelah terikat, saya harus membedah kode besar-besaran agar bisa dideploy ke berbagai infrastruktur cloud. Banyak pelanggan meminta hal ini. Misalnya, jika suatu hari ingin menjual ke Oracle atau Salesforce dan mereka meminta agar bisa dijalankan on-premise, beban untuk menyesuaikan key-value store yang bisa mereka pakai dengan fungsi paket Deno akan jatuh ke saya
    Ini pedang bermata dua. Deno bisa saja berhasil mendorong visi ini ke audiens yang lebih luas, tetapi untuk sementara saya rasa akan melihatnya dengan hati-hati

    • Dalam kasus ini, KV Connect, protokol koneksi jaraknya, juga didokumentasikan: https://github.com/denoland/deno/tree/main/ext/kv#kv-connect
      Saya sempat mencoba kv-connect-kit, implementasi protokol ini dalam TypeScript murni, dan ia menyediakan API klien KV di runtime JavaScript apa pun. Termasuk Cloudflare Workers yang sama sekali tidak memiliki namespace Deno
      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/
      Protokolnya tampaknya bekerja seperti yang dijelaskan, dan menulis backend lain juga terlihat cukup sederhana
    • Saya tidak setuju. Menggabungkan runtime bahasa dengan antarmuka KV tertentu yang terikat pada layanan hosting tertentu adalah kebalikan dari berorientasi masa depan
      Industri teknologi sudah cukup banyak maju untuk keluar dari stack yang terkunci pada vendor, tetapi ini justru mengingatkan pada masa-masa itu
      Saya tidak tahu apa perbedaan praktis antara Deno.KV yang disertakan sebagai bagian dari runtime dan menambahkan import KV di bagian atas file. Yang terakhir bisa diimpor dari mana pun yang kita inginkan, baik di Deno maupun tempat lain
      Lalu, seberapa besar kemungkinan tim Deno menyediakan binding untuk bahasa selain bahasa mereka sendiri? Kalau Google mulai memasukkan primitive khusus Google Cloud secara native ke Go, apakah itu akan disebut berorientasi masa depan?
    • Saya suka Deno, tetapi dengan alasan yang sama saya jadi berhati-hati untuk mengadopsinya. Agar Deno menang, sepertinya para pesaing hosting juga harus didukung sepenuhnya
      Pada saat yang sama, hosting mandirinya sendiri juga harus setara atau lebih baik daripada para pemimpin industri. Jalan lain adalah meninggalkan hosting mandiri, lalu menyediakan solusi multicloud dengan margin tipis di atas adapter mitra hosting. Dengan begitu, Deno tidak perlu bersaing langsung sebagai penyedia hosting
    • Deno hanya mencoba bersaing dengan SaaS JS/TS lain lewat ini. Vercel/NextJS juga punya layanan KV, Cloudflare juga punya, dan dalam kasus lain ada Firebase
      Menurut saya ini bukan berorientasi masa depan, melainkan lebih dekat ke monetisasi Deno sebagai SaaS. Ini adalah hal yang dilakukan semua orang di dunia JavaScript belakangan ini dengan produk “cloud”: menempelkan framework lalu menjual ulang AWS. Karena itulah ada label harganya
      Jika KV Deno bergantung pada FoundationDB, kecil kemungkinan mereka akan aktif membuat adapter untuk database lain. Mengganti teknologi database selalu merupakan pekerjaan besar, karena masing-masing punya kegunaan dan karakteristik performa yang berbeda
    • Menurut saya GC allowing one to return what look like stack allocated pointers from functions lebih karena escape analysis dan SSA, bukan karena garbage collection

  • Argumen bahwa “untuk memanfaatkan infrastruktur cloud publik, pengembang harus mengutak-atik kode boilerplate dan konfigurasi yang rumit sehingga banyak menyita waktu dan energi” sulit saya terima
    Pada akhirnya kita sedang membangun infrastruktur yang harus stabil. Menghabiskan 30 menit untuk mengonfigurasi antrean SQS, teknologi yang sudah teruji, tidak terlihat lebih buruk daripada sepenuhnya memercayai antrean mainan yang dibuat Deno “di atas SQLite / FoundationDB”. Apakah biaya konfigurasi 30 menit dan “developer experience” yang lebih baik benar-benar sepadan dengan risiko itu? Lagi pula, seberapa sering kita mengatur antrean?

    • Menurut saya ini tergantung saya orang seperti apa
      Sebagai programmer hobi, saya tidak terlalu sering memakai penyedia besar seperti AWS atau Google, karena kelihatannya cukup rumit. Kalau sudah terbiasa mungkin tidak seburuk itu
      Saya juga ingin setiap proyek menjadi repositori independen di GitHub. Idealnya, siapa pun bisa dengan mudah menjalankan web app sebagai web app independen mereka sendiri di domain terpisah. Karena saya tidak ingin bertanggung jawab atas data orang lain
      Ini agak mirip dengan use case Sandstorm. Instruksi instalasi seperti “coba secara lokal, lalu buat akun Deno Deploy jika ingin benar-benar memakainya” terdengar cukup masuk akal
    • Banyak orang tidak punya pengalaman dengan AWS atau SQS, dan bahkan orang yang berpengalaman pun tetap harus memikirkannya. Deno memilih pendekatan baterai termasuk, sehingga pengembang bisa mengambil sesuatu dan langsung memakainya
      Jika seseorang menyediakan library setara untuk cloud, pasti akan ada yang mengadopsinya. Dalam kasus Deno, mereka tampaknya mencari masalah umum yang dialami pengembang di ekosistemnya, lalu mencoba menyelesaikannya dengan membundel solusi yang cukup baik
    • Kalau mau ekstrem, menurut saya sekarang lebih baik tidak memakai antrean secara langsung. Mirip seperti memakai HTTP/2 mentah atau mengelola thread sendiri
      Dengan memakai workflow engine yang mengabstraksikan antrean, kita bisa “tinggal menulis kode” tanpa mengelola task, schedule, state, dan retry
      https://www.inngest.com/blog/how-durable-workflow-engines-wo...
      Namun, saya penulis workflow engine, jadi saya bias
    • Dengan logika itu, apa pun yang baru pada dasarnya adalah “proyek mainan”, dan karena hanya AWS yang teruji, berarti tidak ada yang boleh merilis produk baru
    • Bagaimana Anda tahu itu antrean mainan?

  • Dari pengalaman lama menangani “semantik pengiriman setidaknya sekali” dan “kode pengguna”, pengguna tidak benar-benar memahami pengiriman setidaknya sekali
    Begitu pesan dikirim ulang, keluhan pengguna dan insiden akan membanjir
    Menurut saya, entah kita melakukan hal yang nyaris mustahil dan menciptakan semantik pengiriman tepat sekali, atau kita harus selalu mengirim ulang 0,1% dari semua pesan agar pengguna tidak bisa bergantung pada asumsi bahwa pesan hanya dikirim sekali

    • SQS awal pada dasarnya seperti ini. Saya tidak tahu apakah itu disengaja, tetapi berkat itu saya cepat belajar bahwa pengiriman ulang harus dihormati
    • Jika pesan harus idempoten, saya sangat menyarankan untuk membuat integration test di sisi pengirim yang memastikan hal itu

  • Saat ini saya memakai Deno Deploy, dan untuk proyek yang saya buat sendiri, performanya sangat baik dan benar-benar sederhana
    Dari sudut pandang seseorang yang pernah mengembangkan di AWS dalam tim besar, saya senang melihat arus yang menjauh dari kompleksitas agar bisa dengan mudah menjalankan sesuatu tanpa memikirkan konfigurasi. DNS juga sangat sederhana, dan sertifikat SSL otomatisnya benar-benar bagus. Saya sama sekali tidak punya keluhan terhadap arah produk ini, dan saya menantikan roadmap-nya

  • Kalau saya tidak melewatkan sesuatu, tampaknya hanya ada satu antrean untuk setiap instance Deno.openKv()
    Pada versi lokal, mungkin kita bisa membuat beberapa antrean dengan memanggil Deno.openKv("db-2.db") memakai path file SQLite yang berbeda setiap kali, tetapi untuk kebutuhan yang cukup umum, overhead-nya terlihat besar
    Mungkin ini memang gaya arsitektur Deno. Saat membuat aplikasi kompleks dengan Deno, apakah yang diharapkan adalah struktur ala microservice, dengan beberapa skrip bekerja bersama dan masing-masing punya KV store serta antreannya sendiri?

  • Bagaimana harganya?
    Saya kira Deno semacam pengganti Node.js, apakah ada yang saya lewatkan? Bisakah ini dipakai secara lokal atau self-hosting tanpa biaya?

    • Ini sama seperti bagian Deno KV lainnya. Versi open source memakai SQLite, tetapi jika dideploy ke produk cloud Deno, ia akan memakai FoundationDB proprietary sebagai gantinya
      Karena “Queues are built on Deno KV”, penjelasannya adalah di lokal memakai SQLite, sedangkan di Deno Deploy memakai FoundationDB untuk ketersediaan dan throughput maksimum
      Saya menulis sedikit lebih banyak tentang pola ini di sini: https://til.simonwillison.net/deno/deno-kv
    • Menurut artikel itu, saat pengembangan lokal ia memakai SQLite, dan ketika dideploy ke Deno, ia menjadi bagian dari fitur yang disediakan cloud

  • Jika para pengembang kebetulan melihat ini, dari kegunaan KV yang saat ini sudah bagus, sisi kontrol akses sepertinya akan menimbulkan rasa sakit nantinya
    Saya penasaran apakah solusinya hanya “implementasikan sendiri di user space dan jangan membuat bug”, atau apakah ada sesuatu yang direncanakan

    • Saya penasaran apakah yang Anda maksud adalah kontrol akses tingkat pengguna, misalnya ACL untuk pengguna terautentikasi, atau sesuatu yang lain. Jika Anda bisa membagikan pemikiran yang lebih panjang, saya akan terus mengingat kekhawatiran ini

  • Dukungan Jupyter baru-baru ini dan fitur antrean ini membuat saya antusias. Benar-benar keren
    Namun, sepertinya saya tidak akan menulis server dengan Deno lalu menjalankannya di production di server saya sendiri. Saya tidak suka serverless
    Model bisnis Deno dan Bun dibangun di sekitar serverless, yaitu Deno Deploy. Dan Deno Deploy adalah runtime lain lagi
    Hal itu terlihat jelas pada KV dan antrean. Di lokal atau self-hosting, Anda mendapatkan versi yang sekadar hampir berjalan di atas teknologi lain
    Dengan kata lain, Anda akan men-self-host versi Deno yang berbeda dari yang dipakai sebagian besar pelanggan Deno
    Berapa banyak orang yang memakai Deno untuk menjalankan server di hardware mereka sendiri? Kalau jumlahnya kecil, saya lebih baik memakai Node

  • Deno benar-benar menarik. Model bisnis yang layak direalisasikan, usability yang baik, dan tidak ada pekerjaan remeh-temeh konfigurasi yang tidak perlu adalah hal-hal yang bagus

    • Saya sempat mencoba menaruh harapan pada Deno, tapi masih kurang yakin. Saya tidak melihat apa bedanya dengan hal-hal yang sudah berkali-kali dilakukan di masa lalu
      Deno sendiri pada dasarnya adalah Node.js ditambah kompilasi TypeScript otomatis. Biasanya itu hanya berarti perlu satu file konfigurasi tambahan. Saat proyek ini muncul, mereka sangat menonjolkan bahwa ini membebaskan kita dari ekosistem NPM yang berantakan, tetapi pada akhirnya mereka harus berbalik dan menambahkan dukungan NPM, sehingga pembeda itu pun hilang
      Deno Deploy sama seperti layanan sejenis Lambda yang sudah ada puluhan. Penyimpanan KV dan sekarang queue setara dengan Redis, LevelDB, RocksDB, Dynamo, SQS, atau banyak opsi serupa lainnya. Saya masih belum melihat satu pun fitur yang benar-benar membedakan Deno dari yang lain
      Jika Anda lebih suka satu perusahaan menangani semuanya—runtime bahasa, hosting komputasi, dan penyimpanan data—ini mungkin menarik. Namun secara pribadi saya ingin menghindarinya, apalagi jika perusahaan itu belum punya rekam jejak di bidang tersebut
    • Apa alasan Anda percaya bahwa Deno punya model bisnis yang layak direalisasikan?