Deno Queues

 (deno.com)
1 पॉइंट द्वारा GN⁺ 2023-09-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Deno Queues, Deno KV के ऊपर बना एक serverless distributed queue है, जो लंबे समय लेने वाले कामों को asynchronous तरीके से भेजने या भविष्य के किसी समय पर execution schedule करने की सुविधा देता है
  • डेवलपर .enqueue() से message डालते हैं और .listenQueue() से उसे process करते हैं, और इसके लिए अलग queue infrastructure को set up या maintain करने की ज़रूरत नहीं होती
  • लोकल में यह SQLite का उपयोग करता है, जबकि Deno Deploy में FoundationDB का; Deploy message processing के समय V8 isolate को on-demand शुरू करके चलाता है
  • इसकी delivery semantics at-least-once delivery है, इसलिए failure या retry की स्थिति में एक ही message कई बार process हो सकता है
  • अलग से queue billing नहीं है, लेकिन enqueue को KV write और message receive को KV write तथा Deno Deploy request के रूप में गिना जाता है, इसलिए duplicate processing और cost structure दोनों पर साथ में विचार करना चाहिए

Deno Queues क्या काम करता है

  • Deno Queues, Deno KV पर आधारित queue capability है, जिससे application के कुछ processing हिस्सों को asynchronous tasks में भेजा जा सकता है या बाद में चलने वाले काम schedule किए जा सकते हैं
  • Deno का लक्ष्य cloud software development में दोहराए जाने वाले setup और infrastructure configuration को कम करना है, ताकि डेवलपर तेज़ी से design, improve और ship कर सकें
  • Deno KV, FoundationDB पर आधारित persistence option है और अभी open beta में है
  • Queues, Deno KV के ऊपर scalable messaging और background processing management उपलब्ध कराता है

बेसिक API और execution का तरीका

  • Deno Queues के दो core API हैं
    • .enqueue(): नया message queue में डालता है और उसे तुरंत या भविष्य के किसी समय पर deliver करने देता है
    • .listenQueue(): queue से नए message लेकर उन्हें process करने वाले handler के रूप में काम करता है
  • बेसिक flow में Deno.openKv() से KV खोला जाता है, listenQueue में Slack message भेजा जाता है, और enqueue में { delay: 60000 } देकर 60 सेकंड बाद processing कराई जाती है
  • execution environment के अनुसार storage बदलता है
    • लोकल execution में SQLite का उपयोग
    • Deno Deploy पर execution में FoundationDB का उपयोग
  • Deno Deploy में जब message process किया जा सकता है, तब V8 isolate को on-demand चलाकर message dispatch किया जाता है
  • application code को सिर्फ listenQueue handler में नए message receive करने होते हैं, बाकी execution management Deno Deploy संभालता है

delivery guarantee और retry

  • Deno Queues at-least-once delivery की गारंटी देता है
  • ज़्यादातर enqueue किए गए messages के लिए listenQueue handler सिर्फ एक बार call होता है, लेकिन कुछ failure स्थितियों में delivery guarantee बनाए रखने के लिए वही handler कई बार call हो सकता है
  • इसलिए application को duplicate message handling सुरक्षित तरीके से करनी चाहिए
  • अगर listenQueue handler exception throw करता है, तो runtime अपने आप उस call को retry करता है
  • retry तब तक जारी रहती है जब तक success न हो जाए या maximum retry count तक न पहुँच जाए; अभी default maximum 5 बार है
  • maximum retry count तक पहुँचने वाले messages delete कर दिए जाते हैं

KV atomic transaction के साथ उपयोग

  • Deno Queues को KV atomic transactions के साथ जोड़ा जा सकता है
  • अगर message को KV transaction के हिस्से के रूप में enqueue किया जाए, तो वह तभी queue में जाएगा जब पूरा transaction सफल होगा
  • उदाहरण flow में Bob और Liz के balance को check और update करने के बाद दोनों को notification messages enqueue किए जाते हैं
    • check(bob, liz) से state verify की जाती है
    • Bob का balance कम किया जाता है और Liz का balance बढ़ाया जाता है
    • enqueue से Liz और Bob, दोनों के लिए notification messages जोड़े जाते हैं
    • commit() सफल होने पर ही पूरे changes और enqueue लागू होते हैं
  • listenQueue handler के अंदर भी Deno KV state update की जा सकती है
  • हर message के लिए update सिर्फ एक बार करने के लिए nonce को store और delete करने के तरीके से duplicate processing prevention flow बनाया जा सकता है
    • enqueue के समय nonce को साथ में store किया जाता है
    • processing के समय nonce न मिले तो तुरंत return किया जाता है
    • processing सफल होने पर nonce delete किया जाता है और counter व balance state साथ में update की जाती है

ऐसे use cases जहाँ queue उपयुक्त है

  • queue सर्वर को asynchronous processing ऑफलोड करने और future jobs schedule करने देता है, इसलिए application scaling में उपयोगी है

  • scheduled email notifications

    • जब user द्वारा शुरू किया गया काम लंबा चलता हो या completion response का इंतज़ार ज़रूरी न हो, तब काम को queue में भेजकर server या app की responsiveness बनाए रखी जा सकती है
    • उदाहरण में welcome_email message को तुरंत enqueue किया जाता है, जबकि survey_email message को { delay: 259200000 } के साथ delayed execution के लिए भेजा जाता है

  • reliable webhook processing

    • webhook request को तुरंत process करने के बजाय queue में डालने से response और actual processing को अलग किया जा सकता है
    • Oak और Queues को साथ इस्तेमाल करके /webhook POST request मिलने पर request body को queue में डाला जाता है और HTTP 200 return किया जाता है
    • वास्तविक webhook processing, listenQueue में processWebHook के जरिए asynchronous रूप से होती है

  • Slack·Discord bots

    • Queues का उपयोग Discord या Slack bots बनाने में भी किया जा सकता है
    • Slack reminder app example Deno Queues से एक सरल Slack reminder app बनाने का उदाहरण है
    • Discord bot example Deno Queues से giveaway बनाता है और users को एक क्लिक में भाग लेने देता है
    • queue के और use cases docs.deno.com पर देखे जा सकते हैं

pricing का तरीका

  • Deno Queues के लिए अलग dedicated billing item नहीं है
  • cost की गणना Deno KV operations और Deno Deploy requests के आधार पर होती है
    • message enqueue: हर enqueue action, 1 KV write operation के बराबर है
    • message receive: हर received message पर 1 KV write operation और 1 request charge लगता है
  • billing का ढाँचा ऐसा है कि सिर्फ इस्तेमाल किए गए operations के लिए ही शुल्क लिया जाता है

documentation और roadmap

  • संबंधित documentation और API reference
  • scalable web apps और servers बनाने के लिए background jobs को queue में भेजने वाली संरचना चाहिए, लेकिन पारंपरिक तरीकों में setup के कई चरण होते हैं
  • Deno Queues runtime में built-in है और Deno Deploy infrastructure पर चलता है, जिससे कुछ पंक्तियों के code में serverless distributed queue का उपयोग किया जा सकता है
  • Deno Queues को Deno KV, web standards APIs, npm, all-in-one modern tooling के साथ इस रूप में रखा गया है कि web development अधिक सरल और productive बने
  • feedback और feature requests Discord या deploy_feedback issues के माध्यम से भेजे जा सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-29
Hacker News की राय

  • अभी-अभी लोकल SQLite वर्ज़न के अंदर झांका और नोट्स整理 किए: https://til.simonwillison.net/deno/deno-kv#user-content-deno...
    सबसे दिलचस्प हिस्सा शायद इस feature में इस्तेमाल होने वाला schema है:
    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);

    • लगभग समान fields वाली 2 tables बनाकर rows को इधर-उधर ले जाना आम तौर पर खराब practice नहीं माना जाता?
      indexes तो इसी काम के लिए design नहीं किए गए हैं क्या?
    • “open source business model” के नजरिए से खास तौर पर दिलचस्प बात यह है कि Deno अपने framework की core functionality में ऐसे features जोड़ रहा है जिन्हें global-scale upgrade के रूप में ठीक से सिर्फ उसका अपना SaaS platform ही उपलब्ध करा सकता है
      यह काफी नया है, लेकिन थोड़ा बेचैन भी करता है। commercialization तो जाहिर है करनी ही होगी, लेकिन इसे पूरी तरह closed तरीके से करना जरूरी नहीं था; extension layer के लिए BSL या PolyForm जैसे दूसरे licenses भी इस्तेमाल किए जा सकते थे

  • मुझे लगता है कि Deno यहाँ जो दिशा साध रहा है, वह काफ़ी future-oriented है
    मैं इस साल पहली बार Go इस्तेमाल कर रहा हूँ, और भाषा के कुछ हिस्से C से बहुत मिलते-जुलते हैं। C से अलग चीज़ों—जैसे garbage collection की वजह से functions से ऐसे values return कर पाना जो stack-allocated pointers जैसी दिखती हैं—के अलावा, map[string]string जैसी built-in सुविधाएँ भी स्वाभाविक रूप से शामिल हैं। 2023 के बाद कोई नई भाषा बनाते समय map type संभालने के लिए built-in syntax न होना लगभग अजीब लगता है
    इसलिए web server-केंद्रित ecosystem में उन primitive capabilities के लिए libraries, और शायद किसी दिन language syntax तक, होना logical लगता है जिन्हें हम अक्सर इस्तेमाल करते हैं। मुझे अपना कोई आख़िरी project याद नहीं जिसमें distributed web server में cache के लिए key-value store, locking mechanism, या temporary queue तक न हो। key-value store के बिना distributed system कुछ-कुछ map type के बिना programming language जैसा लगता है, और यह सच में Swiss Army knife जैसी technology है
    संभावित समस्या यह है कि Deno इस रास्ते पर अकेले चल रहा है। अभी Deno जो नए features जोड़ रहा है, वे competing platforms पर भी मिलेंगे या नहीं, यह पक्का कहना मुश्किल है, और API को open source में public कर भी दें, तो भी वह Deno namespace में है; इसलिए AWS पर FoundationDB के बजाय Redis पर switch करना चाहूँ तो यह बस वैसे ही काम करेगा या नहीं, पता नहीं
    इसी वजह से Deno से बचने का मन होता है। Syntax और exposed features सच में आकर्षक हैं, लेकिन चिंता है कि dependency बन जाने के बाद, code को कई cloud infrastructures पर deployable बनाने के लिए कहीं बड़ी surgery न करनी पड़े। बहुत से customers इसकी माँग करते हैं। उदाहरण के लिए, अगर किसी दिन Oracle या Salesforce को बेचना चाहूँ और वे on-premises execution की शर्त रखें, तो वहाँ उपलब्ध key-value store को Deno package functionality के हिसाब से कैसे fit करूँ—यह बोझ मुझ पर आ जाएगा
    यह दोधारी तलवार है। Deno इस vision को व्यापक audience तक push करने में सफल भी हो सकता है, लेकिन फिलहाल मैं इसे सावधानी से ही देखूँगा

    • इस मामले में remote connection protocol KV Connect भी documented है: https://github.com/denoland/deno/tree/main/ext/kv#kv-connect
      मैंने इस protocol को pure TypeScript में implement करने वाले kv-connect-kit को थोड़ा इस्तेमाल किया है, और यह किसी भी JavaScript runtime में KV client API देता है। इसमें Cloudflare Workers भी शामिल हैं, जहाँ Deno namespace बिल्कुल नहीं है
      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/
      Protocol वर्णन के मुताबिक काम करता दिखता है, और दूसरे backends लिखना भी काफ़ी आसान लगता है
    • सहमत नहीं हूँ। language runtime को किसी खास hosting service से बंधे specific KV interface के साथ जोड़ना future-oriented होने के उलट है
      Tech industry vendor lock-in वाले stacks से बाहर निकलने में काफ़ी आगे बढ़ चुकी है, लेकिन यह तो उलटे उन्हीं दिनों की याद दिलाता है
      मुझे समझ नहीं आता कि Deno.KV का runtime का हिस्सा होना और file के सबसे ऊपर import KV जोड़ने में व्यावहारिक अंतर क्या है। दूसरा तरीका आप Deno हो या कहीं और, जहाँ चाहें वहाँ से import कर सकते हैं
      और Deno team अपनी भाषा के अलावा दूसरी languages के लिए bindings देगी, इसकी संभावना कितनी है? अगर Google, Go में Google Cloud-specific primitive capabilities native रूप से डालना शुरू कर दे, तो क्या आप उसे future-oriented कहेंगे?
    • Deno पसंद है, लेकिन इसी वजह से adoption को लेकर सावधान हो जाता हूँ। Deno को जीतना है तो शायद hosting competitors को भी पूरी तरह support करना होगा
      साथ ही self-hosting भी industry leaders जितनी या उनसे बेहतर होनी चाहिए। दूसरा रास्ता यह हो सकता है कि self-hosting छोड़ दे और hosting partner adapters के ऊपर पतला margin लगाकर multi-cloud solution दे। तब Deno को hosting provider के रूप में सीधे compete करने की ज़रूरत नहीं रहेगी
    • Deno इससे सिर्फ़ दूसरे JS/TS SaaS से compete करना चाहता है। Vercel/NextJS के पास भी KV service है, Cloudflare के पास भी है, और अन्य cases में Firebase है
      मुझे यह future-oriented से ज़्यादा Deno को SaaS के रूप में monetize करने जैसा लगता है। आजकल JavaScript world में हर कोई “cloud” product के साथ यही कर रहा है—framework जोड़कर AWS को resell करना। इसलिए इस पर price tag लगा है
      अगर Deno का KV FoundationDB पर निर्भर है, तो दूसरे databases के लिए adapters actively बनाने की संभावना भी कम लगती है। Database technology बदलना हमेशा बड़ा काम होता है, क्योंकि हर एक की use cases और performance characteristics अलग होती हैं
    • GC allowing one to return what look like stack allocated pointers from functions मुझे garbage collection की वजह से कम, escape analysis और SSA की वजह से ज़्यादा लगता है

  • “पब्लिक क्लाउड इंफ्रास्ट्रक्चर का इस्तेमाल करने के लिए boilerplate code और जटिल सेटिंग्स में खंगालना पड़ता है, जिससे डेवलपर का बहुत समय और ऊर्जा खर्च होती है” वाली दलील मुझे ठीक से समझ नहीं आती
    आखिरकार हम ऐसा इंफ्रास्ट्रक्चर बना रहे हैं जिसे स्थिर होना चाहिए। परखी हुई तकनीक SQS queue सेट करने में 30 मिनट लगाना, Deno द्वारा “SQLite / FoundationDB के ऊपर” बनाई गई खिलौना queue पर पूरी तरह भरोसा करने से बुरा नहीं लगता। क्या 30 मिनट की setup cost और बेहतर “developer experience” सचमुच उस जोखिम को उठाने लायक है? वैसे भी queue कितनी बार सेट करनी पड़ती है?

    • मुझे लगता है यह इस पर निर्भर करता है कि मैं किस तरह का व्यक्ति हूँ
      hobby programmer के तौर पर मैं AWS या Google जैसे बड़े providers का ज़्यादा इस्तेमाल नहीं करता, क्योंकि वे काफ़ी जटिल लगते हैं। अगर आदत हो तो शायद इतने बुरे न हों
      साथ ही मैं हर project को GitHub पर अलग repository के रूप में रखना चाहता हूँ। आदर्श रूप से, web app को कोई भी व्यक्ति अलग domain पर अपनी स्वतंत्र web app की तरह आसानी से चला सके। क्योंकि मैं दूसरों के data की ज़िम्मेदारी नहीं लेना चाहता
      यह कुछ हद तक Sandstorm use case जैसा है। “local पर test करें, और असल में इस्तेमाल करना हो तो Deno Deploy account बनाएं” जैसी installation guidance काफ़ी reasonable लगती है
    • बहुत से लोगों को AWS या SQS का अनुभव नहीं है, और जिनके पास अनुभव है उन्हें भी अब भी ध्यान देना पड़ता है। Deno ने batteries included approach अपनाई है, ताकि developer कुछ लेकर तुरंत इस्तेमाल कर सके
      अगर कोई cloud के लिए equivalent library देता है तो निश्चित तौर पर लोग उसे अपनाएंगे। Deno के मामले में लगता है कि वे अपने ecosystem के developers की common problems पहचानकर, एक ठीक-ठाक solution bundle करके हल करना चाहते हैं
    • थोड़ा तीखा कहूँ तो, अब queue को सीधे इस्तेमाल न करना ही बेहतर लगता है। यह raw HTTP/2 इस्तेमाल करने या threads को सीधे manage करने जैसा है
      queue को abstract करने वाला workflow engine इस्तेमाल करें तो tasks, schedules, state, retries manage किए बिना “बस code लिखना” संभव है
      https://www.inngest.com/blog/how-durable-workflow-engines-wo...
      हालांकि, मैं workflow engine author हूँ, इसलिए मेरा bias है
    • उस logic के हिसाब से तो जो भी नया आता है वह मूल रूप से “toy project” है, और सिर्फ AWS ही validated है, इसलिए किसी को नया product launch नहीं करना चाहिए
    • आपको कैसे पता कि वह toy queue है?

  • “at-least-once delivery semantics” और “user code” से जुड़े पुराने अनुभव के आधार पर, users at-least-once delivery को ठीक से नहीं समझते
    जैसे ही message redeliver होता है, users की शिकायतें और outages की बाढ़ आ जाती है
    या तो लगभग असंभव काम करके exactly-once delivery semantics invent करें, या फिर मुझे लगता है कि हर message के 0.1% को हमेशा redeliver करना चाहिए, ताकि users इस पर निर्भर न कर सकें कि message सिर्फ एक बार deliver होगा

    • शुरुआती SQS व्यवहार में कुछ ऐसा ही था। यह जानबूझकर था या नहीं, पता नहीं, लेकिन इससे जल्दी सीख गया कि redelivery का सम्मान करना ज़रूरी है
    • अगर messages idempotent होने चाहिए, तो मैं strongly recommend करता हूँ कि sender side पर इसे guarantee करने वाले integration tests ज़रूर बनाएं

  • मैं अभी Deno Deploy इस्तेमाल कर रहा हूँ, और solo project के हिसाब से performance शानदार है और यह वाकई simple है
    बड़ी team में AWS development कर चुके व्यक्ति के रूप में, settings के बारे में सोचे बिना आसानी से deploy कर पाने के लिए complexity से बाहर निकलने का यह trend अच्छा लगता है। DNS भी बहुत आसान था और automatic SSL certificates सचमुच बेहतरीन थे। इस product की दिशा को लेकर मुझे कोई शिकायत नहीं है, और roadmap को लेकर भी उत्साहित हूँ

  • अगर मैं कुछ miss नहीं कर रहा, तो ऐसा लगता है कि हर Deno.openKv() instance में सिर्फ एक queue है
    local version में हर बार अलग SQLite file path के साथ Deno.openKv("db-2.db") call करके कई queues बनाई जा सकती हैं, लेकिन एक काफ़ी common requirement के लिए overhead बड़ा लगता है
    शायद यह Deno की architectural style हो सकती है। क्या complex app को Deno में बनाते समय expectation यह है कि कई scripts साथ काम करें, और हर एक के पास अपना KV store और queue हो, यानी microservices जैसी structure?

    • सही है। फिलहाल single queue ही है
      core developers में से एक ने Discord पर confirm किया: https://discord.com/channels/684898665143206084/115671428253...
      quote करें तो: “हाँ। फिलहाल सिर्फ single queue support है। हालांकि single queue में कई types के messages multiplex किए जा सकते हैं।”

  • pricing कैसी है?
    मैंने Deno को एक तरह का Node.js alternative समझा था, क्या मैं कुछ miss कर रहा हूँ? क्या इसे local या self-hosting में बिना cost के इस्तेमाल किया जा सकता है?

    • यह Deno KV के बाकी हिस्सों जैसा ही है। open source version SQLite इस्तेमाल करता है, लेकिन Deno के cloud product पर deploy करने पर इसके बजाय proprietary FoundationDB इस्तेमाल होता है
      “Queues are built on Deno KV” इसलिए local में SQLite इस्तेमाल होता है, और Deno Deploy में maximum availability और throughput के लिए FoundationDB इस्तेमाल होता है, यही explanation है
      इस pattern पर मैंने यहाँ थोड़ा और लिखा है: https://til.simonwillison.net/deno/deno-kv
    • लेख के अनुसार, development के दौरान local में SQLite इस्तेमाल होता है, और Deno पर deploy करने पर यह cloud-provided feature का हिस्सा बन जाता है

  • अगर developers देख रहे हों, तो मौजूदा शानदार KV usability में access control वाला हिस्सा आगे चलकर दर्द दे सकता है
    जानना चाहूँगा कि solution बस “user space में खुद implement करें और bugs न बनाएं” है, या कुछ planned है

    • क्या आप user-level access control की बात कर रहे हैं, जैसे authenticated users के लिए ACL, या कुछ और? अगर आप अपने लंबे thoughts share करें तो मैं इस concern को ध्यान में रखता रहूँगा

  • हालिया Jupyter support और यह queue feature उम्मीद जगाते हैं। सचमुच शानदार चीज़ें हैं
    लेकिन मुझे नहीं लगता कि मैं Deno में server लिखकर उसे अपने server पर production में चलाऊँगा। मुझे serverless पसंद नहीं है
    Deno और Bun का business model serverless, यानी Deno Deploy, के इर्द-गिर्द बना है। और Deno Deploy अपने आप में एक और runtime है
    KV और queue में यह बात साफ़ दिखती है। local या self-hosting में आपके पास दूसरी technologies के ऊपर टिकाया गया, किसी तरह चलने वाला version होता है
    यानी आप Deno का ऐसा version self-host करेंगे जो Deno के ज़्यादातर customers द्वारा इस्तेमाल किए जाने वाले version से अलग है
    अपने hardware पर server चलाने के लिए Deno इस्तेमाल करने वाले लोग कितने होंगे? अगर वह संख्या कम है, तो मैं बेहतर है Node इस्तेमाल करूँगा

  • Deno वाकई दिलचस्प है। व्यवहार्य बिज़नेस मॉडल, अच्छी usability, और बेकार की configuration वाली झंझटों का न होना—ये सब शानदार हैं

    • मैंने Deno से उम्मीदें रखने की कोशिश की, लेकिन समझ नहीं आ रहा। यह अतीत में अनगिनत बार हो चुकी चीज़ों से कैसे अलग है, यह दिखता नहीं
      Deno अपने आप में मूलतः Node.js में automatic TypeScript compilation जोड़ने जैसा है। सामान्य तौर पर बस एक extra config file की ज़रूरत पड़ती। जब project आया था, तो गड़बड़ NPM ecosystem से बाहर निकलने को इसकी बड़ी खासियत बताया गया था, लेकिन आखिरकार उन्हें पलटकर NPM support जोड़ना पड़ा और वह फर्क भी खत्म हो गया
      Deno Deploy पहले से मौजूद दर्जनों Lambda-जैसी services जैसा ही है। KV storage और अब queues, Redis, LevelDB, RocksDB, Dynamo, SQS या ढेरों मिलते-जुलते विकल्पों के बराबर हैं। अब तक मैंने Deno में ऐसा कोई feature नहीं देखा जो उसे बाकी चीज़ों से सच में अलग करता हो
      अगर आप चाहें कि language runtime, compute hosting और data store—तीनों एक ही company संभाले, तो यह आकर्षक हो सकता है। लेकिन व्यक्तिगत रूप से मैं इससे बचना चाहूंगा, खासकर अगर उस company का उस क्षेत्र में कोई track record न हो
    • आपको क्यों लगता है कि Deno के पास व्यवहार्य बिज़नेस मॉडल है?