Demo chat application from the article using Durable Objects:<p>- <a href="https://edge-chat-demo.cloudflareworkers.com" rel="nofollow">https://edge-chat-demo.cloudflareworkers.com</a><p>- A Public Room (to joint test):<p>hackernews<p>- Source: <a href="https://github.com/cloudflare/workers-chat-demo" rel="nofollow">https://github.com/cloudflare/workers-chat-demo</a><p>Insanely awesome feature add (much needed for truly “serverless” application development). The power to scale here without insane infrastructure headache is amazing.<p>One day some kid is totally going to build a single-person billion dollar company from his mom’s basement.
Wow, very cool! I didn't see the string "mobile code" in this press release, but that's essentially what this is, right? Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! Plus, the persistence is clever - I'm guessing that makes the semantics of mobility much easier to deal with.<p>I love the migration to nearby edge nodes, but here's a question to any Cloudflare employees around: Have you given any thought to automatically migrating Durable Objects to end user devices?<p>That has security implications of course, so if you've dismissed the idea previously because the security issues are too hard to surface to the developer, that's reasonable.
> <i>I'm going to be honest: naming this product was hard, because it's not quite like any other cloud technology that is widely-used today.</i><p>On a superficial skim it looks like a tuple space; they were heavily researched in the 80s and 90s. JavaSpaces emerged in the late 90s but never took off.<p>Scala folks are keen on Actor models (Lightbend have been using the term "Stateful Serverless" for a while now), as are Erlang and Elixir folks.<p>I guess the key here is "widely-used".<p>Edit: this sounds even more arrogant than I intended. Sorry. I just feel bad for tuple space researchers (including my Honours supervisor). They laboured mightily in the 80s and 90s and their reward was to be largely ignored by industry.
What is the size limits for a durable object?<p>The read/write limit per second?<p>That usually the first things I want to know about my cloud primitives...<p>(Credits for at-least being clear about consistency which is always my very first question)
Interesting, i didn't see how security works? Is there backpressure on message senders? Any ordering guarantees? Are messages queued so activated objects can reconstruct state? Can passivation warmth be controlled? Can objects support multiple threads? Can objects move? Failover?
> I'm going to be honest: naming this product was hard, because it's not quite like any other cloud technology that is widely-used today.<p>Perhaps I'm missing something important, but isn't this quite similar to Orleans grains and other distributed actors?
Some wanky theory about computing and the design of programs follows. (Not out of scope considering the philosophical underpinnings of this product and the "edge", etc.)<p>The chat demo says:<p>> With the introduction of modules, we're experimenting with allowing text/data
blobs to be uploaded and exposed as synthetic modules. We uploaded `chat.html`
as a module of type `application/octet-stream`, i.e. just a byte blob. So when
we import it as `HTML` here, we get the HTML content as an `ArrayBuffer`[...]<p><pre><code> import HTML from "chat.html";
</code></pre>
I've thought a lot about this for the work that I've been doing. From an
ergonomics standpoint, it's really attractive, and the only other viable
alternatives are (a) dynamically reading the asset, or (b) settling on using
some wrapper pattern so the original asset can be represented in the host
language, e.g.:<p><pre><code> export const IMAGE_DATA =
"iVBORw0KGgoAAAANSUhEUgAAAD8AAAA/..." +
"..."
export const HTML = `
<!-- totally the HTML I wanted to use -->
`;
</code></pre>
... which is <i>much</i> less attractive than the "import" way.<p>Ultimately I ended up going with something closer to the latter, and there wasn't even any reluctance about it on my part by the time I made the decision—I was pretty enthusiastic
after having an insight verging on a minor epiphany.<p>I'd been conflicted around the same time also about representing "aliens" (cf
Bracha) from other languages and integrating with them. I slapped my head
after realizing that the entire reason for my uneasiness about the latter "data islands"
approach was because I wasn't truly embracing objects and that these two problems (foreign integration and foreign representation) were very closely related. Usually you <i>don't</i> actually want `HTML`,
for example, and focusing on it is missing the forest for the trees. I.e.,
forget whatever you were planning with your intention to leave it to the
caller/importer to define procedures for operating on this inert data. Make it a class
that can be instantiated as an object that knows things about itself (e.g.
the mimetype) and that you can send messages to, because that's what your
program <i>really</i> wants it to be, anyway. Once you're at that point, the "wrapper" approach is much more palatable, because it's really not even a wrapper anymore.
If I'm getting this right, it's essentially immediately consistent distributed state for workers. They could have called it simply "Workers State" :)<p>Now in all seriousness, this is super impressive. Congrats to the CF team!
Is it possible to query across objects? Like if you wanted to find every object instance which had “string” written to it?<p>Can the data store only store alphanumeric or can you write blobs? Could a chat app store uploads inside the object?
Now this is one of the times I wish I had at least one idea for an application, because this is the kind of thing I'd like to try out.<p>Oh, well, I'll wait until it's an open beta or generally available.
are updates to durable objects guaranteed to be exactly once?if an update is sent but the connection between client and object are dropped, how is that handled?
Is this similar to Azure Durable Functions?<p><a href="https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview" rel="nofollow">https://docs.microsoft.com/en-us/azure/azure-functions/durab...</a><p>From what I understand these features are a nice way to implement a serverless Actor Model. I was surprised to see no reference to it on the CloudFlare page.
Is there only a single instance of the example Counter object globally and as there are no additional await'ed calls between the get and put operations, the atomicity is guaranteed? Is the object then prevented from getting instantiated on any other worker?<p>Can this result in a deadlock if I access DurableClass(1), then delayed DurableClass(2) in one worker and DurableClass(2) and delayed DurableClass(1) in another worker?
All hail the Cloudflare Gods! They are benevolent gods, say I!<p>And today they have given into us a new, powerful bounty of storage with a delicious API!
This is awesome, and I'm so excited to read through the chat.mjs code. I might consider trying this out for a project. It means I need to use cloudflare? I wonder if in the future, this could become more standard, and one could do something similar on their own infrastructure (maybe such a solution already exists, open sourced somewhere?)
I’m wondering what sort of durability guarantees there are in case of an outage? It seems like replicating durable storage would add latency?<p>Is there going to be Jepsen testing for this?
Really interesting, seems like it has some unique abilities.<p>Signed up for beta invite -- does anyone happen to know whether all interested parties are admitted?