Ask HN: Anyone here using Cloudflare’s durable objects?

2 pointsby saimiamvor 5 Jahren2 comments

I need to get some concepts cleared because it looks to be something I could use right away for a project of mine. Bears mentioning that I come from the AWS world so I’m trying to get DOs from that perspective.

1. Is a durable object just a singleton JavaScript object which can write to a file?

2. Say I have a config JSON. Can a DO be used to update that json without worrying about one updater overwriting someone else’s updates? Basically, do DOs guarantee updates?

3. Is a DO in any way related to databases like DynamoDB or object stores like S3? I don’t think it is but if it is, how so?

4. Is a Cloudflare worker the same as a Lambda@Edge? So a DO is just a backend for (essentially) a bunch of Lambda@Edge functions?

Any help would be very appreciated? I’ve read the CF docs but they don’t give a conceptual overview of the product

2 comments

greg-mvor 5 Jahren

Hey! I’m the PM for DO.

1) A Durable Object is a global singleton instance of a Cloudflare Worker that is addressed by an ID. You define that Worker’s behavior via a JavaScript class. That Worker can then write to a persistent storage API, which is backed by a strongly-consistent KV database.

2) yes, the storage API is strongly consistent.

As an example, say you had a Durable Object for each user’s configuration. You’d have a class called Config, and you’d access the Durable Objects associated with that class by calling their id from a Worker.

When a network request is received that routes your Worker, we’d run your Worker code in whatever datacenter we receive the request in.

If that Worker needs to access the user’s config data it would make a request for the Config Durable Object with that user’s id. That request is forwarded to a singleton Worker (which we call a Durable Object) running somewhere on our network. All of the requests for that User’s config data originating all across Cloudflare’s network will execute serially on that Durable Object, and can modify storage associated with the Object.

This means the Durable Object can both store state associated with the User’s config, but also expose methods and functions related to the user (for example, a function resetLogin() that resets their password).

3) while the DO has access to a KV storage API, they more closely resemble the Actor pattern or Azure’s Durable Entities.

4) they’re similar. Lambda@edge runs a container at a small number of AWS edge locations, while a Worker runs JavaScript or WASM code at a Cloudflare’s edge in response to a network request. Workers are much lighter weight, less expensive and have better performance characteristics, while supporting a smaller list of programming languages.

Let me know if you have more questions!

saimiamvor 5 Jahren

Thank you so much for your reply.

> All of the requests for that User’s config data originating all across Cloudflare’s network will execute serially on that Durable Object, and can modify storage associated with the Object.

I'm liking the sound of this but I need a little more clarity.

Say a user config contains their name and optionally, a twitter handle. The user is logged in on machine 1. The user's virtual assistant is logged in machine 2.

Now, the user adds the twitter handle while basically simultaneously, their VA edits the name to fix a typo. What will be the state of the DO at the end of this? Will the person coding the DO have to write code to resolve the conflicts or is there some sort of `git merge` type algo running which handles updates?

Bonus question, what if both the user and VA updated the name? Even `git merge` can't handle this so I'm guessing either you discard the older request or leave it to the developer to handle this.

Edit: I'm genuinely interested in using DOs and I'm not trying to ask gotcha questions. The documentation just flits past some of the implementation details (or maybe I'm not understanding something which you have already answered)