by ispivey on 9/28/20, 1:02 PM with 91 comments
by _ahs0 on 9/28/20, 1:23 PM
- https://edge-chat-demo.cloudflareworkers.com
- A Public Room (to joint test):
hackernews
- Source: https://github.com/cloudflare/workers-chat-demo
Insanely awesome feature add (much needed for truly “serverless” application development). The power to scale here without insane infrastructure headache is amazing.
One day some kid is totally going to build a single-person billion dollar company from his mom’s basement.
by catern on 9/28/20, 3:38 PM
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?
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.
by jacques_chester on 9/28/20, 4:14 PM
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.
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.
I guess the key here is "widely-used".
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.
by jopsen on 9/28/20, 10:10 PM
The read/write limit per second?
That usually the first things I want to know about my cloud primitives...
(Credits for at-least being clear about consistency which is always my very first question)
by toddh on 9/28/20, 3:15 PM
by ramchip on 9/28/20, 3:04 PM
Perhaps I'm missing something important, but isn't this quite similar to Orleans grains and other distributed actors?
by cxr on 9/28/20, 4:10 PM
The chat demo says:
> 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`[...]
import HTML from "chat.html";
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.: export const IMAGE_DATA =
"iVBORw0KGgoAAAANSUhEUgAAAD8AAAA/..." +
"..."
export const HTML = `
<!-- totally the HTML I wanted to use -->
`;
... which is much less attractive than the "import" way.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.
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 don't 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 really 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.
by pier25 on 9/28/20, 3:57 PM
Now in all seriousness, this is super impressive. Congrats to the CF team!
by agotterer on 9/29/20, 3:37 AM
Can the data store only store alphanumeric or can you write blobs? Could a chat app store uploads inside the object?
by luord on 9/29/20, 2:14 AM
Oh, well, I'll wait until it's an open beta or generally available.
by phn on 9/28/20, 1:52 PM
by visarga on 9/28/20, 2:29 PM
by asdev on 9/28/20, 5:13 PM
by vyrotek on 9/28/20, 3:36 PM
https://docs.microsoft.com/en-us/azure/azure-functions/durab...
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.
by dividuum on 9/28/20, 2:29 PM
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?
by ilaksh on 9/29/20, 1:18 AM
And today they have given into us a new, powerful bounty of storage with a delicious API!
by kovek on 9/29/20, 2:41 AM
by skybrian on 9/28/20, 4:06 PM
Is there going to be Jepsen testing for this?
by gavinray on 9/28/20, 2:59 PM
Signed up for beta invite -- does anyone happen to know whether all interested parties are admitted?
by akritrime on 9/28/20, 3:58 PM
by proppy on 9/29/20, 12:18 AM
by asim on 9/28/20, 9:37 PM