Puan
28,728
Çözümler
0
- Konum
- Freanchey
- Mesajlar
- 3,047
- Katılım
- 2 Eki 2026
- Tepkime puanı
- 3,565
- Puan
- 28,728
- Web sitesi
- glomaxgpt.com
The Deno team is joining Cloudflare to radically simplify self-hosting Workers and Durable Objects so developers can use the same primitives in more places.For what this means and how it came about, here’s the story from Ryan Dahl, Senior Principal Engineer, and Kenton Varda, Distinguished Engineer.
The Deno team is joining Cloudflare, and we're merging workerd and celld! For more on what's happening to the Deno runtime and our various efforts, see my post on the Deno blog.
Long ago, I stood in a Berlin warehouse and introduced Node.js with a 500-line JavaScript IRC server and live audience participation. Node.js was an exploration of what a purely asynchronous programming model could enable. Async I/O was already known to be important for fast servers, but it was difficult to wield. Removing sync networking made it easier to build systems that previously required much more machinery. What made the IRC demo exciting was how little code it took.
I started Deno to find more powerful abstractions like this — looking for places where we could simplify and remove capabilities while giving engineers ever more power. With Deno, we improved the experience of writing JavaScript, but we didn’t fundamentally change what developers had to assemble around the runtime. The bigger problems are around networked applications: distributing computation, coordinating state, data storage in general, and autoscaling to meet demand.
Something about that old IRC demo has always bothered me — it was a single server, single thread even. It could handle many user connections, but it would start getting slow if you had too many. Scaling IRC eventually means multiple machines with the channels shared across them. A modern chat app also needs to store message history, user accounts, and other data.
Could the programming model make partitioning across machines part of the design from the start?
The solution clicked into focus when I read about Cloudflare's Durable Objects. It provided a very powerful abstraction: the distributed singleton with a SQLite database. Each Durable Object is like a small, individually addressable server with its own relational database. Its JavaScript execution is single-threaded (which is easy to reason about), it handles WebSockets, and its local SQLite database can be accessed synchronously. By building a chat application using one DO per channel, you have sharded your data and WebSocket connections, and thus made your application scalable.
Much more than chat can be built with DOs. On top of this abstraction other services can be built: Queues, KV, Durable Execution (CF's Workflow API), even Git storage. The Durable Object abstraction is simple yet incredibly powerful.
But running this model outside of Cloudflare has remained difficult. Cloudflare’s network is great — but there are a million reasons one might want to run it themselves. Workerd is already open source, but its Durable Objects support is limited to a single instance. What I wanted was the distributed version: IRC channels spread across machines, with the platform handling placement, routing, and durable storage. The power of this abstraction is how it scales. That's why I started celld.
Building and operating Deno Deploy taught me how complicated cloud infrastructure could become: multiple public clouds, multiple databases, and deeply entangled services. With celld, I wanted the opposite: one binary, written in Rust, with object storage as its only external service dependency.
What excites me is the leverage this model gives developers: compute, relational databases, queues, and real-time communication primitives designed for applications distributed across machines. To run it, you manage many instances of celld and a single object storage bucket. Your application can contain many services without each requiring a separate infrastructure project. This is much closer to the simplicity I've been chasing since that first Node.js demo.
We’re joining Cloudflare to make the Workers programming model a mainstream way to build servers. By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure.
The Deno team is joining Cloudflare, and we're merging workerd and celld! For more on what's happening to the Deno runtime and our various efforts, see my post on the Deno blog.
Long ago, I stood in a Berlin warehouse and introduced Node.js with a 500-line JavaScript IRC server and live audience participation. Node.js was an exploration of what a purely asynchronous programming model could enable. Async I/O was already known to be important for fast servers, but it was difficult to wield. Removing sync networking made it easier to build systems that previously required much more machinery. What made the IRC demo exciting was how little code it took.
I started Deno to find more powerful abstractions like this — looking for places where we could simplify and remove capabilities while giving engineers ever more power. With Deno, we improved the experience of writing JavaScript, but we didn’t fundamentally change what developers had to assemble around the runtime. The bigger problems are around networked applications: distributing computation, coordinating state, data storage in general, and autoscaling to meet demand.
Something about that old IRC demo has always bothered me — it was a single server, single thread even. It could handle many user connections, but it would start getting slow if you had too many. Scaling IRC eventually means multiple machines with the channels shared across them. A modern chat app also needs to store message history, user accounts, and other data.
Could the programming model make partitioning across machines part of the design from the start?
The solution clicked into focus when I read about Cloudflare's Durable Objects. It provided a very powerful abstraction: the distributed singleton with a SQLite database. Each Durable Object is like a small, individually addressable server with its own relational database. Its JavaScript execution is single-threaded (which is easy to reason about), it handles WebSockets, and its local SQLite database can be accessed synchronously. By building a chat application using one DO per channel, you have sharded your data and WebSocket connections, and thus made your application scalable.
Much more than chat can be built with DOs. On top of this abstraction other services can be built: Queues, KV, Durable Execution (CF's Workflow API), even Git storage. The Durable Object abstraction is simple yet incredibly powerful.
But running this model outside of Cloudflare has remained difficult. Cloudflare’s network is great — but there are a million reasons one might want to run it themselves. Workerd is already open source, but its Durable Objects support is limited to a single instance. What I wanted was the distributed version: IRC channels spread across machines, with the platform handling placement, routing, and durable storage. The power of this abstraction is how it scales. That's why I started celld.
Building and operating Deno Deploy taught me how complicated cloud infrastructure could become: multiple public clouds, multiple databases, and deeply entangled services. With celld, I wanted the opposite: one binary, written in Rust, with object storage as its only external service dependency.
What excites me is the leverage this model gives developers: compute, relational databases, queues, and real-time communication primitives designed for applications distributed across machines. To run it, you manage many instances of celld and a single object storage bucket. Your application can contain many services without each requiring a separate infrastructure project. This is much closer to the simplicity I've been chasing since that first Node.js demo.
We’re joining Cloudflare to make the Workers programming model a mainstream way to build servers. By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure.