Deno คิว

 (deno.com)
1 คะแนน โดย GN⁺ 2023-09-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Deno Queues คือ คิวแบบกระจายสำหรับสภาพแวดล้อมเซิร์ฟเวอร์เลส ที่สร้างอยู่บน Deno KV ซึ่งช่วยส่งต่องานที่ใช้เวลานานไปทำแบบอะซิงโครนัส หรือกำหนดเวลาให้รันในอนาคตได้
  • นักพัฒนาเพียงใส่ข้อความด้วย .enqueue() และประมวลผลด้วย .listenQueue() ก็พอ โดยไม่ต้องตั้งค่าหรือดูแลโครงสร้างพื้นฐานของคิวแยกต่างหาก
  • ในเครื่องโลคัลใช้ SQLite ส่วนบน Deno Deploy ใช้ FoundationDB และ Deploy จะเรียก V8 isolate แบบ on-demand ขึ้นมาทำงานเมื่อถึงเวลาประมวลผลข้อความ
  • รูปแบบการส่งมอบเป็น at-least-once delivery ดังนั้นในกรณีเกิดความล้มเหลวหรือมีการลองใหม่ ข้อความเดียวกันอาจถูกประมวลผลมากกว่าหนึ่งครั้ง
  • ไม่มีค่าบริการคิวแยกต่างหาก แต่การ enqueue จะคิดเป็นการเขียน KV ส่วนการรับข้อความจะคิดเป็นการเขียน KV และคำขอ Deno Deploy จึงต้องพิจารณาทั้งการประมวลผลซ้ำและโครงสร้างต้นทุนไปพร้อมกัน

สิ่งที่ Deno Queues รับหน้าที่

  • Deno Queues เป็นความสามารถด้านคิวที่อิงกับ Deno KV ซึ่งช่วยย้ายบางส่วนของการประมวลผลในแอปพลิเคชันไปเป็น งานอะซิงโครนัส หรือกำหนดเวลางานที่จะทำภายหลังได้
  • เป้าหมายของ Deno คือการลดงานตั้งค่าซ้ำ ๆ และการจัดโครงสร้างพื้นฐานในการพัฒนาซอฟต์แวร์คลาวด์ พร้อมมอบองค์ประกอบพื้นฐานที่ช่วยให้นักพัฒนาออกแบบ ปรับปรุง และเปิดตัวได้รวดเร็วยิ่งขึ้น
  • Deno KV เป็นตัวเลือกการจัดเก็บข้อมูลแบบคงทนที่สร้างบน FoundationDB และขณะนี้อยู่ในสถานะ โอเพนเบตา
  • Queues มอบความสามารถด้านการส่งข้อความที่ขยายได้และการจัดการงานเบื้องหลังบน Deno KV

API พื้นฐานและวิธีการทำงาน

  • API หลักของ Deno Queues มีอยู่สองตัว
    • .enqueue(): ใส่ข้อความใหม่ลงคิวและให้ส่งมอบทันทีหรือในเวลาที่กำหนดในอนาคต
    • .listenQueue(): ใช้เป็นแฮนด์เลอร์เพื่อรับและประมวลผลข้อความใหม่จากคิว
  • โฟลว์พื้นฐานคือเปิด KV ด้วย Deno.openKv() ส่งข้อความ Slack ใน listenQueue และกำหนด { delay: 60000 } ใน enqueue เพื่อให้ประมวลผลหลังจาก 60 วินาที
  • ที่เก็บข้อมูลจะแตกต่างกันตามสภาพแวดล้อมการรัน
    • เมื่อรันในเครื่องโลคัลจะใช้ SQLite
    • เมื่อรันบน Deno Deploy จะใช้ FoundationDB
  • บน Deno Deploy ระบบจะรัน V8 isolate แบบ on-demand เมื่อถึงเวลาที่ข้อความพร้อมให้ประมวลผล แล้วจึง dispatch ข้อความ
  • โค้ดของแอปพลิเคชันเพียงรับข้อความใหม่ผ่านแฮนด์เลอร์ listenQueue ส่วนการจัดการการทำงานที่เหลือเป็นหน้าที่ของ Deno Deploy

การรับประกันการส่งมอบและการลองใหม่

  • Deno Queues รับประกันแบบ at-least-once delivery
  • ข้อความส่วนใหญ่ที่ enqueue จะเรียกแฮนด์เลอร์ listenQueue เพียงครั้งเดียว แต่ในบางสถานการณ์ที่ล้มเหลว อาจมีการเรียกแฮนด์เลอร์เดิมหลายครั้งเพื่อรับประกันการส่งมอบ
  • ดังนั้นแอปพลิเคชันจึงต้องรองรับ การประมวลผลข้อความซ้ำ อย่างปลอดภัย
  • หากแฮนด์เลอร์ listenQueue โยนข้อยกเว้น รันไทม์จะลองเรียกใหม่โดยอัตโนมัติ
  • การลองใหม่จะดำเนินต่อไปจนกว่าจะสำเร็จหรือถึงจำนวนครั้งสูงสุด โดยค่าดีฟอลต์ปัจจุบันคือ 5 ครั้ง
  • ข้อความที่ถึงจำนวนครั้งสูงสุดแล้วจะถูกลบออก

ใช้งานร่วมกับ KV atomic transaction

  • Deno Queues สามารถใช้งานร่วมกับ KV atomic transactions ได้
  • หาก enqueue ข้อความเป็นส่วนหนึ่งของ KV transaction ข้อความจะถูกใส่เข้าคิวก็ต่อเมื่อทั้ง transaction สำเร็จเท่านั้น
  • โฟลว์ตัวอย่างคือการตรวจสอบและอัปเดตยอดคงเหลือของ Bob และ Liz แล้ว enqueue ข้อความแจ้งเตือนให้ทั้งสองคน
    • ใช้ check(bob, liz) เพื่อตรวจสอบสถานะ
    • ลดยอดคงเหลือของ Bob และเพิ่มยอดคงเหลือของ Liz
    • ใช้ enqueue เพื่อเพิ่มข้อความแจ้งเตือนให้ Liz และ Bob ตามลำดับ
    • การเปลี่ยนแปลงทั้งหมดและการ enqueue จะมีผลก็ต่อเมื่อ commit() สำเร็จ
  • ภายในแฮนด์เลอร์ listenQueue ก็สามารถอัปเดตสถานะของ Deno KV ได้เช่นกัน
  • หากต้องการให้อัปเดตรายการต่อข้อความเพียงครั้งเดียว สามารถจัดโฟลว์ ป้องกันการประมวลผลซ้ำ โดยเก็บและลบ nonce ได้
    • บันทึก nonce ไปพร้อมกับการ enqueue
    • ระหว่างประมวลผล หากไม่มี nonce ให้คืนค่าทันที
    • เมื่อประมวลผลสำเร็จ ให้ลบ nonce และอัปเดตตัวนับกับสถานะยอดคงเหลือพร้อมกัน

กรณีใช้งานที่เหมาะกับคิว

  • คิวช่วยให้เซิร์ฟเวอร์ส่งต่องานประมวลผลแบบอะซิงโครนัสและกำหนดเวลางานในอนาคตได้ จึงมีประโยชน์ต่อการขยายแอปพลิเคชัน

  • การแจ้งเตือนอีเมลแบบตั้งเวลา

    • เมื่อมีงานที่ผู้ใช้เริ่มต้นแล้วใช้เวลานาน หรือไม่จำเป็นต้องรอการตอบกลับเมื่อเสร็จสิ้น สามารถส่งงานเข้าไปในคิวเพื่อคงความตอบสนองของเซิร์ฟเวอร์หรือแอปไว้ได้
    • ในตัวอย่างจะ enqueue ข้อความ welcome_email ทันที และให้ข้อความ survey_email รันแบบหน่วงเวลาด้วย { delay: 259200000 }

  • การประมวลผลเว็บฮุกที่เชื่อถือได้

    • หากไม่ประมวลผลคำขอเว็บฮุกทันที แต่ใส่ลงคิวก่อน ก็จะแยกการตอบกลับออกจากการประมวลผลจริงได้
    • เมื่อใช้ Oak ร่วมกับ Queues หากรับคำขอ POST ที่ /webhook ก็จะนำเนื้อหาคำขอใส่ลงคิวและส่งกลับ HTTP 200
    • การประมวลผลเว็บฮุกจริงจะทำแบบอะซิงโครนัสใน listenQueue ผ่าน processWebHook

  • บอท Slack และ Discord

    • Queues ยังใช้สร้างบอทสำหรับ Discord หรือ Slack ได้ด้วย
    • ตัวอย่างแอป Slack reminder เป็นกรณีสร้างแอปเตือนความจำบน Slack แบบง่ายด้วย Deno Queues
    • ตัวอย่างบอท Discord ใช้ Deno Queues ทำ giveaway และเปิดให้ผู้ใช้เข้าร่วมได้ด้วยการคลิกครั้งเดียว
    • ตัวอย่างการใช้งานคิวเพิ่มเติมดูได้ที่ docs.deno.com

รูปแบบการคิดค่าใช้จ่าย

  • Deno Queues ไม่มีรายการคิดค่าบริการเฉพาะแยกต่างหาก
  • ค่าใช้จ่ายจะคำนวณตามการทำงานของ Deno KV และคำขอ Deno Deploy
    • การ enqueue ข้อความ: การ enqueue แต่ละครั้งเทียบเท่ากับการเขียน KV 1 ครั้ง
    • การรับข้อความ: ต่อข้อความที่รับ 1 ข้อความ จะเกิดการเขียน KV 1 ครั้งและค่าคำขอ 1 ครั้ง
  • ระบบจะคิดค่าใช้จ่ายเฉพาะงานที่ใช้งานจริง

เอกสารและโรดแมป

  • เอกสารที่เกี่ยวข้องและ API อ้างอิง
  • การสร้างเว็บแอปและเซิร์ฟเวอร์ที่ขยายได้จำเป็นต้องมีรูปแบบการส่งงานเบื้องหลังเข้าไปในคิว แต่แนวทางเดิมมักมีขั้นตอนการตั้งค่าจำนวนมาก
  • Deno Queues ถูกฝังมาในรันไทม์และทำงานบนโครงสร้างพื้นฐานของ Deno Deploy ทำให้สามารถใช้ คิวแบบกระจายสำหรับสภาพแวดล้อมเซิร์ฟเวอร์เลส ได้ด้วยโค้ดเพียงไม่กี่บรรทัด
  • Deno Queues ถูกวางให้เป็นองค์ประกอบหนึ่งร่วมกับ Deno KV, web standards APIs, npm, all-in-one modern tooling เพื่อทำให้การพัฒนาเว็บเรียบง่ายและมีประสิทธิผลมากขึ้น
  • สามารถส่งฟีดแบ็กและคำขอฟีเจอร์ได้ผ่าน Discord หรือ deploy_feedback issues

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-29
ความคิดเห็นจาก Hacker News

  • เพิ่งเจาะดูภายในของ เวอร์ชัน SQLite แบบโลคัล แล้วจดบันทึกไว้: https://til.simonwillison.net/deno/deno-kv#user-content-deno...
    ส่วนที่น่าสนใจที่สุดน่าจะเป็น 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);

    • การสร้าง 2 ตาราง ที่มีฟิลด์แทบเหมือนกันแล้วคอยย้ายแถวไปมา โดยทั่วไปน่าจะเป็นแนวปฏิบัติที่ไม่ดีไม่ใช่หรือ?
      index ไม่ได้ถูกออกแบบมาเพื่อกรณีแบบนั้นพอดีหรือ?
    • สิ่งที่น่าสนใจเป็นพิเศษจากมุมมอง “โมเดลธุรกิจโอเพนซอร์ส” คือ Deno กำลังใส่ฟีเจอร์เข้าไปในแกนหลักของเฟรมเวิร์ก ซึ่งมีแต่แพลตฟอร์ม SaaS ของตัวเองเท่านั้นที่น่าจะให้บริการในรูปแบบอัปเกรดระดับ global scale ได้ดี
      ค่อนข้างใหม่ แต่ก็ชวนกังวลเล็กน้อย แน่นอนว่าต้องทำเชิงพาณิชย์อยู่แล้ว แต่ไม่จำเป็นต้องปิดทั้งหมดก็ได้ และสำหรับชั้นส่วนขยายก็น่าจะใช้ไลเซนส์อื่นอย่าง BSL หรือ PolyForm ได้เช่นกัน

  • ผมมองว่าทิศทางที่ Deno เล็งไว้ตรงนี้ค่อนข้าง มองไปข้างหน้า
    ปีนี้ผมเพิ่งเริ่มใช้ Go และบางส่วนของภาษาก็คล้าย C มาก นอกจากสิ่งที่ต่างจาก C เช่นการที่ garbage collection ทำให้สามารถ return ค่าที่ดูเหมือนพอยน์เตอร์ที่จัดสรรบน stack จากฟังก์ชันได้แล้ว ฟีเจอร์ built-in อย่าง map[string]string ก็ถูกใส่เข้ามาอย่างเป็นธรรมชาติด้วย ถ้าจะสร้างภาษาใหม่หลังปี 2023 ผมรู้สึกว่าแทบจะเป็นเรื่องไม่สมเหตุสมผลเลยถ้าไม่มี syntax built-in สำหรับจัดการ map type
    ดังนั้นจึงดูสมเหตุสมผลที่ ecosystem ที่มีเว็บเซิร์ฟเวอร์เป็นศูนย์กลางจะมีไลบรารีสำหรับ primitive features ที่เราใช้กันบ่อย ๆ และบางทีสักวันอาจถึงขั้นมี syntax ในภาษาด้วยซ้ำ ผมนึกโปรเจกต์ล่าสุดที่เป็น distributed web server แล้วไม่มี key-value store สำหรับ cache, กลไก lock หรือแม้แต่ queue ชั่วคราวไม่ออกเลย distributed system ที่ไม่มี key-value store คล้าย ๆ กับภาษาโปรแกรมมิงที่ไม่มี map type อยู่เลือน ๆ และเป็นเทคโนโลยีที่เหมือนมีด Swiss Army จริง ๆ
    ปัญหาที่อาจเกิดขึ้นคือ Deno กำลังเดินเส้นทางนี้อยู่คนเดียว ตอนนี้ยังยากจะมั่นใจว่าฟีเจอร์ใหม่ ๆ ที่ Deno เพิ่มเข้ามาจะมีให้ในแพลตฟอร์มคู่แข่งด้วยหรือไม่ และแม้จะเปิด API เป็นโอเพนซอร์ส แต่เพราะมันอยู่ใน namespace Deno ก็ไม่รู้ว่าจะใช้งานได้ทันทีหรือเปล่าเวลาที่อยากเปลี่ยนจาก FoundationDB เป็น Redis บน AWS
    เลยทำให้รู้สึกอยากเลี่ยง Deno อยู่บ้าง syntax และฟีเจอร์ที่ expose ออกมานั้นน่าดึงดูดมากจริง ๆ แต่ก็เป็นห่วงว่าหลังจากผูกติดไปแล้ว จะต้องผ่าตัดโค้ดครั้งใหญ่เพื่อให้ deploy ไปยังหลาย ๆ cloud infrastructure ได้หรือไม่ ลูกค้าจำนวนมากต้องการสิ่งนี้ เช่น ถ้าวันหนึ่งอยากขายให้ Oracle หรือ Salesforce แล้วเขาต้องการให้รันแบบ on-premises ผมก็จะต้องแบกรับการหาวิธีนำ key-value store ที่ฝั่งนั้นใช้ได้มาปรับให้เข้ากับฟังก์ชันของแพ็กเกจ Deno
    มันเป็นดาบสองคม Deno อาจประสบความสำเร็จในการผลักดันวิสัยทัศน์นี้ไปสู่ผู้ใช้วงกว้างขึ้นก็ได้ แต่ในระยะนี้ผมคงจะมองอย่างระมัดระวัง

    • ในกรณีนี้ KV Connect ซึ่งเป็นโปรโตคอลการเชื่อมต่อระยะไกลก็มีเอกสารไว้ด้วย: https://github.com/denoland/deno/tree/main/ext/kv#kv-connect
      ผมลองใช้ kv-connect-kit ซึ่งเป็น implementation ของโปรโตคอลนี้ด้วย TypeScript ล้วน ๆ มานิดหน่อย และมันให้ KV client API ได้บน JavaScript runtime ใด ๆ รวมถึง Cloudflare Workers ที่ไม่มี 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 / เดโม: https://keyspace.deno.dev/
      โปรโตคอลดูเหมือนจะทำงานตามที่อธิบายไว้ และการเขียน backend อื่น ๆ ก็ดูค่อนข้างง่าย
    • ไม่เห็นด้วย การผูก language runtime เข้ากับ KV interface เฉพาะ ที่ผูกกับ hosting service รายใดรายหนึ่งนั้นเป็นสิ่งตรงข้ามกับการมองไปข้างหน้า
      อุตสาหกรรมเทคโนโลยีก้าวหน้าไปพอสมควรในการหลุดพ้นจาก stack ที่ผูกกับ vendor แต่สิ่งนี้กลับทำให้นึกถึงยุคนั้นเสียมากกว่า
      ผมไม่เห็นว่าการที่ Deno.KV ถูกรวมเป็นส่วนหนึ่งของ runtime กับการเพิ่ม import KV ไว้บนสุดของไฟล์มีความต่างเชิงปฏิบัติอะไร อย่างหลังสามารถ import ได้จากที่ที่ต้องการ ไม่ว่าจะเป็น Deno หรือที่อื่น
      แล้วมีโอกาสแค่ไหนที่ทีม Deno จะให้ bindings สำหรับภาษาอื่นนอกจากภาษาของตัวเอง? ถ้า Google เริ่มใส่ primitive features เฉพาะ Google Cloud เข้าไปใน Go แบบ native คุณจะเรียกว่ามองไปข้างหน้าหรือเปล่า?
    • ผมชอบ Deno แต่ด้วยเหตุผลเดียวกันจึงระมัดระวังในการนำมาใช้ ถ้า Deno จะชนะได้ ก็คงต้องรองรับ คู่แข่งด้าน hosting อย่างเต็มที่ด้วย
      ในขณะเดียวกัน self-hosting ก็ต้องดีเท่าหรือดีกว่าผู้นำในอุตสาหกรรม อีกทางหนึ่งคือเลิก self-hosting แล้วเสนอ multicloud solution ที่บวก margin บาง ๆ บน adapter ของพาร์ตเนอร์ hosting แทน แบบนั้น Deno ก็ไม่จำเป็นต้องแข่งขันโดยตรงในฐานะ hosting provider
    • Deno แค่พยายามใช้สิ่งนี้แข่งกับ JS/TS SaaS รายอื่น ๆ เท่านั้น Vercel/NextJS ก็มีบริการ KV, Cloudflare ก็มี และกรณีอื่น ๆ ก็มี Firebase
      ผมมองว่านี่ไม่ใช่การมองไปข้างหน้าเท่าไร แต่ใกล้เคียงกับการ monetize Deno ในฐานะ SaaS มากกว่า เป็นกระแสที่ทุกคนในโลก JavaScript ทำกับผลิตภัณฑ์ “cloud” ทุกวันนี้ นั่นคือเอา framework มาครอบแล้วขายต่อ AWS จึงมีป้ายราคาติดอยู่
      ถ้า KV ของ Deno พึ่งพา FoundationDB ก็ดูไม่น่าจะมีแนวโน้มสูงที่จะทำ adapter สำหรับฐานข้อมูลอื่นอย่างจริงจัง เพราะการเปลี่ยนเทคโนโลยีฐานข้อมูลเป็นเรื่องใหญ่เสมอ และแต่ละตัวก็มี use case กับลักษณะ performance ต่างกัน
    • GC allowing one to return what look like stack allocated pointers from functions ผมมองว่าเป็นเพราะ escape analysis กับ SSA มากกว่า ไม่ใช่เพราะ garbage collection

  • ผมไม่ค่อยเห็นด้วยกับตรรกะที่ว่า “ถ้าจะใช้โครงสร้างพื้นฐาน public cloud ก็ต้องไปไล่ดู boilerplate code กับการตั้งค่าที่ซับซ้อน ซึ่งกินเวลาและพลังงานของนักพัฒนาไปมาก”
    สุดท้ายแล้วเรากำลังสร้างโครงสร้างพื้นฐานที่ต้องมีความเสถียร การใช้เวลา 30 นาทีตั้งค่า คิว SQS ซึ่งเป็นเทคโนโลยีที่ผ่านการพิสูจน์แล้ว ดูไม่ได้แย่กว่าการเชื่อใจคิวของเล่นที่ Deno สร้าง “บน SQLite / FoundationDB” แบบเต็มร้อย ต้นทุนการตั้งค่า 30 นาทีกับ “ประสบการณ์นักพัฒนา” ที่ดีขึ้น คุ้มค่าพอให้รับความเสี่ยงนั้นจริงหรือ? แล้วปกติเราต้องตั้งค่าคิวบ่อยแค่ไหนกัน?

    • ผมคิดว่าเรื่องนี้ขึ้นอยู่กับว่าเราเป็นคนแบบไหน
      ในฐานะโปรแกรมเมอร์งานอดิเรก ผมไม่ค่อยใช้ผู้ให้บริการรายใหญ่อย่าง AWS หรือ Google เพราะมันดูค่อนข้างซับซ้อน ถ้าคุ้นเคยแล้วอาจไม่ได้แย่ขนาดนั้นก็ได้
      อีกอย่าง ผมอยากให้แต่ละโปรเจกต์อยู่เป็น repository แยกใน GitHub ตามอุดมคติแล้ว คนอื่นควรจะสามารถรันเว็บแอปขึ้นมาเป็นเว็บแอปอิสระของตัวเองบนโดเมนแยกได้ง่าย ๆ เพราะผมไม่อยากต้องรับผิดชอบข้อมูลของคนอื่นด้วย
      เรื่องนี้คล้ายกับ use case ของ Sandstorm อยู่บ้าง คำแนะนำการติดตั้งที่ว่า “ลองทดสอบในเครื่องก่อน และถ้าจะใช้งานจริงให้สร้างบัญชี Deno Deploy” ฟังดูสมเหตุสมผลทีเดียว
    • หลายคนไม่มีประสบการณ์กับ AWS หรือ SQS และแม้แต่คนที่มีประสบการณ์ก็ยังต้องคอยใส่ใจอยู่ดี Deno เลือกแนวทางแบบ รวมแบตเตอรี่มาให้ เพื่อให้นักพัฒนาหยิบอะไรบางอย่างมาใช้ได้ทันที
      ถ้ามีใครทำไลบรารีที่เทียบเท่าสำหรับคลาวด์ออกมา ก็คงมีคนรับไปใช้อย่างแน่นอน กรณีของ Deno ดูเหมือนพยายามหาปัญหาร่วมที่นักพัฒนาใน ecosystem ของตัวเองเจอ แล้วแพ็กวิธีแก้ที่พอใช้ได้มาแก้ปัญหา
    • ถ้าพูดแรง ๆ ผมคิดว่าตอนนี้ควรเลี่ยงการใช้คิวโดยตรงแล้ว คล้ายกับการใช้ HTTP/2 ดิบ ๆ หรือจัดการเธรดเอง
      ถ้าใช้ workflow engine ที่ abstract คิวให้ ก็จะ “เขียนโค้ดอย่างเดียว” ได้โดยไม่ต้องจัดการงาน, schedule, state, retry
      https://www.inngest.com/blog/how-durable-workflow-engines-wo...
      แต่ผมเป็นคนเขียน workflow engine เอง จึงมีอคติอยู่
    • ถ้าตรรกะแบบนั้น ของใหม่ ๆ ก็เท่ากับเป็น “โปรเจกต์ของเล่น” โดยปริยาย และเพราะมีแค่ AWS ที่ผ่านการพิสูจน์แล้ว ก็แปลว่าไม่ควรมีใครออกผลิตภัณฑ์ใหม่เลย
    • รู้ได้อย่างไรว่านั่นเป็นคิวของเล่น?

  • จากประสบการณ์เก่าที่เคยทำกับ “semantics แบบส่งอย่างน้อยหนึ่งครั้ง” และ “โค้ดของผู้ใช้” ผู้ใช้ไม่เข้าใจ การส่งอย่างน้อยหนึ่งครั้ง อย่างถูกต้อง
    ทันทีที่มีการส่งข้อความซ้ำ เสียงบ่นจากผู้ใช้และ incident ก็จะถาโถมเข้ามา
    ผมคิดว่าต้องทำสิ่งที่แทบเป็นไปไม่ได้ให้สำเร็จแล้วประดิษฐ์ semantics แบบส่งตรงครั้งเดียวขึ้นมา หรือไม่ก็ต้องส่งข้อความซ้ำเสมอ 0.1% ของทุกข้อความ เพื่อไม่ให้ผู้ใช้พึ่งพาว่ามันจะถูกส่งแค่ครั้งเดียว

    • SQS ในยุคแรก ๆ เป็นแบบนี้แทบจะจริง ๆ ไม่รู้ว่าเป็นความตั้งใจหรือเปล่า แต่ก็ทำให้เรียนรู้ได้เร็วว่าต้องเคารพการส่งซ้ำ
    • ถ้าข้อความต้องเป็นแบบ idempotent ผมแนะนำอย่างยิ่งให้สร้าง integration test ที่รับประกันเรื่องนี้ฝั่งผู้ส่งด้วย

  • ตอนนี้ผมใช้ Deno Deploy อยู่ สำหรับโปรเจกต์ที่ทำคนเดียว ประสิทธิภาพยอดเยี่ยมและเรียบง่ายจริง ๆ
    ในฐานะคนที่เคยพัฒนา AWS ในทีมใหญ่ ผมดีใจที่เห็นกระแสการหลุดพ้นจากความซับซ้อน ให้สามารถ deploy ได้ง่ายโดยไม่ต้องคิดเรื่องการตั้งค่า DNS ก็ง่ายมาก และใบรับรอง SSL อัตโนมัติก็เยี่ยมจริง ๆ ผมไม่มีข้อร้องเรียนเลยกับทิศทางที่ผลิตภัณฑ์นี้มุ่งไป และตั้งตารอ roadmap ด้วย

  • ถ้าผมไม่ได้พลาดอะไรไป ดูเหมือนว่าแต่ละ instance ของ Deno.openKv() จะมี คิวเดียว เท่านั้น
    ในเวอร์ชัน local อาจสร้างหลายคิวได้โดยเรียก Deno.openKv("db-2.db") ด้วย path ไฟล์ SQLite ที่ต่างกันทุกครั้ง แต่เมื่อเทียบกับความต้องการที่ค่อนข้างพบได้บ่อยแล้ว overhead ดูสูงไป
    บางทีนี่อาจเป็นสไตล์สถาปัตยกรรมของ Deno ก็ได้ เวลาสร้างแอปซับซ้อนด้วย Deno เขาคาดหวังโครงสร้างแบบ microservices ที่มีหลายสคริปต์ทำงานร่วมกัน และแต่ละตัวมี KV store กับคิวของตัวเองหรือเปล่า?

    • ใช่แล้ว ตอนนี้มีแค่ คิวเดียว
      หนึ่งใน core developer ยืนยันใน Discord แล้ว: https://discord.com/channels/684898665143206084/115671428253...
      อ้างอิงว่า: “ถูกต้องครับ ตอนนี้รองรับเฉพาะคิวเดียว อย่างไรก็ตาม ในคิวเดียวสามารถ multiplex ข้อความหลายประเภทได้”

  • ราคาเป็นอย่างไร?
    ผมคิดว่า Deno เป็นเหมือน ตัวทดแทน Node.js แบบหนึ่ง หรือผมพลาดอะไรไป? สิ่งนี้ใช้แบบ local หรือ self-hosting ได้โดยไม่มีค่าใช้จ่ายไหม?

    • เรื่องนี้เป็นแบบเดียวกับส่วนอื่นของ Deno KV เวอร์ชันโอเพนซอร์สใช้ SQLite แต่ถ้า deploy ไปยังผลิตภัณฑ์คลาวด์ของ Deno ก็จะใช้ FoundationDB แบบ proprietary แทน
      เพราะ “Queues are built on Deno KV” จึงอธิบายได้ว่า local ใช้ SQLite และบน Deno Deploy ใช้ FoundationDB เพื่อ availability และ throughput สูงสุด
      ผมเขียนเพิ่มเติมเกี่ยวกับ pattern นี้ไว้ที่นี่เล็กน้อย: https://til.simonwillison.net/deno/deno-kv
    • ตามบทความ ระหว่างพัฒนาในเครื่องจะใช้ SQLite และเมื่อ deploy ไปยัง Deno ก็จะกลายเป็นส่วนหนึ่งของฟีเจอร์ที่ผู้ให้บริการคลาวด์มีให้

  • ถ้านักพัฒนาเห็นอยู่ ตอนนี้ usability ของ KV ยอดเยี่ยม แต่ฝั่ง access control น่าจะสร้างความเจ็บปวดในภายหลัง
    ผมสงสัยว่าวิธีแก้คือแค่ “ไป implement เองใน user space และอย่าสร้างบั๊ก” หรือมีอะไรที่วางแผนไว้แล้วหรือเปล่า

    • หมายถึง access control ระดับผู้ใช้ เช่น ACL สำหรับผู้ใช้ที่ authenticated แล้ว หรือหมายถึงอย่างอื่น? ถ้าแชร์ความคิดที่ยาวกว่านี้ได้ ผมจะคอยคำนึงถึงความกังวลนี้ต่อไป

  • การรองรับ Jupyter ล่าสุดกับฟีเจอร์คิวครั้งนี้น่าตื่นเต้น เป็นสิ่งที่เจ๋งจริง ๆ
    แต่ผมคงไม่เขียนเซิร์ฟเวอร์ด้วย Deno แล้วเอาขึ้น production บนเซิร์ฟเวอร์ของตัวเอง ผมไม่ชอบ serverless
    โมเดลธุรกิจของ Deno และ Bun สร้างขึ้นรอบ serverless หรือก็คือ Deno Deploy และ Deno Deploy ก็เป็น runtime อีกตัวหนึ่ง
    เรื่องนี้เห็นชัดใน KV และคิว ถ้าใช้ local หรือ self-hosting คุณจะได้เวอร์ชันที่พอถูไถให้ทำงานได้บนเทคโนโลยีอื่น
    กล่าวคือ คุณจะ self-host Deno เวอร์ชันที่ต่างจากเวอร์ชันที่ลูกค้าส่วนใหญ่ของ Deno ใช้
    จะมีคนใช้ Deno เพื่อรันเซิร์ฟเวอร์บนฮาร์ดแวร์ของตัวเองสักเท่าไร? ถ้าจำนวนนั้นน้อย ผมขอใช้ Node ดีกว่า

  • Deno น่าสนใจจริง ๆ จุดที่ยอดเยี่ยมคือมี โมเดลธุรกิจที่เป็นไปได้จริง, ใช้งานง่าย และไม่มีงานจุกจิกด้านการตั้งค่าที่ไม่จำเป็น

    • ผมพยายามจะคาดหวังกับ Deno แล้ว แต่ก็ยังไม่แน่ใจ ไม่เห็นว่ามันต่างจากสิ่งที่เคยทำกันมาแล้วนับครั้งไม่ถ้วนในอดีตอย่างไร
      ตัว Deno เองโดยเนื้อแท้แล้วคือ Node.js ที่เพิ่มการคอมไพล์ TypeScript อัตโนมัติเข้าไป เดิมทีแค่ต้องมีไฟล์ตั้งค่าเพิ่มอีกไฟล์หนึ่งเท่านั้น ตอนโปรเจกต์ออกมา จุดขายใหญ่คือการหลุดพ้นจาก ecosystem ของ NPM ที่รกเลอะเทอะ แต่ท้ายที่สุดก็ต้องหันกลับมาเพิ่มการรองรับ NPM และจุดแตกต่างนั้นก็หายไป
      Deno Deploy ก็เหมือนบริการแนว Lambda ที่มีอยู่แล้วเป็นสิบ ๆ ตัว ส่วน KV store และตอนนี้คือคิว ก็เทียบได้กับ Redis, LevelDB, RocksDB, Dynamo, SQS หรือทางเลือกคล้าย ๆ กันอีกมากมาย ผมยังไม่เห็นฟีเจอร์ใดเลยที่ทำให้ Deno แตกต่างจากตัวอื่น ๆ ได้จริง
      ถ้าคุณชอบให้บริษัทเดียวรับผิดชอบทั้ง language runtime, compute hosting และ data store มันอาจมีเสน่ห์ก็ได้ แต่โดยส่วนตัวผมอยากหลีกเลี่ยง โดยเฉพาะถ้าบริษัทนั้นยังไม่มีผลงานพิสูจน์ตัวเองในด้านนั้น
    • อะไรทำให้คุณเชื่อว่า Deno มี โมเดลธุรกิจที่เป็นไปได้จริง?