Deno adds scaleable messaging with new Queues feature, sparks debate about proprietary services

Deno adds scaleable messaging with new Queues feature, sparks debate about proprietary services

Deno has previewed Queues, a messaging system which enables asynchronous processing of long-running tasks.

Queues are built on Deno KV, a key-value database also currently in preview, which itself is built on Apple’s open source FoundationDB, a distributed key-value store. Deno Queues implements two APIs, .enqueue which pushes messages into the queue for guaranteed delivery, and .listenqueue which is a handler for messages received from the queue. Delivery is guaranteed at least once, but may “in some failure instances” be repeated, so code must be able to handle duplicates correctly. Messages may be part of a Deno KV transaction in which case all or none will be enqueued, enabling use cases such as financial transactions.

Use cases for Queues include keeping applications responsive during lengthy operations, scheduling future work such as follow-up emails, or processing webhooks (internet callbacks). 

Deno Queues can run locally using Deno KV configured to run on SQLite rather than FoundationDB, or on Deno’s hosted Deno Deploy and Deno KV. In this latter case customers pay per Deno KV operation and Deno Deploy request. Deno pricing shows for example that a Pro plan provides for KV reads up to 45,000 per day and 30,000 writes.

Queues has received a warm reception as an important new feature though there are initial limitations. Currently, only a single queue is supported. “At the very least, you should have multiple named queues and multiple listeners,” said a comment in the Deno Discord forum, getting the response that “multiple listening topics is on the roadmap.”

Although the Deno runtime is open source, Deno’s hosting platform is not. With regard to Deno KV, the team explained that “While FoundationDB provides the necessary mechanisms of a robust distributed database, there’s still several challenges when turning that into a seamless JavaScript-native experience that works within our Deno Deploy platform.” The consequence is that there is an element of lock-in when deploying a production application hosted by Deno. Hosted services form the business model of the Deno project.

Developer Simon Willison examined both Deno KV and Deno Queues and found this “particularly interesting in terms of open source business models: they’re baking a core feature into their framework which their SaaS platform is uniquely positioned to offer as a global-scale upgrade.”

Views vary on the merits of this. “I feel I want to avoid Deno. Even if the syntax and exposed features are really attractive, I’m worried about becoming locked in and then having to do a lot of surgery to code to make it deployable on multiple cloud infrastructures. That is a requirement from a lot of clients,” said one developer on Hacker News, though another said that “the Deno runtime itself is not tied to the Deno Deploy hosting service. The KV feature in the Deno runtime can be used without the hosting service.”

Others noted similar patterns in Vercel’s services. Vercel is the sponsor of Next.js, a framework which has special status in React as the main implementation of React Server Components. “Serverless deploys require providers to support the Next.js Build API … there is no open implementation of this API,” remarked a developer.

It is a discussion which proves once again the challenges of funding open source development.