cc @Walshy | Pages

Is that a way to get a DO bound directly to your Pages site?

This seems like it might be a good starting point https://github.com/Girish21/remix-cloudflare-workers-template

Am I right in thinking with this approach you end up with a single worker deployed with Pages interacting with a DO?

If so it would be great if the documentation touched on it

Yes, thanks. I'll investigate myself now.

YES!!! That helped me to figure it out. It was a bunch of little things, but having the working example helped me get past them all. The last one was odd. It looks like the url you pass to the DO stub fetch handler must look like this "http://whatever-the-hell-you-want-because-it-gets-dropped/the/url/the/DO/actually/receives"

It shouldn’t be dropped? It just doesn’t affect where the request is actually routed

Yeah I really dont understand why they made it require a full url instead of allowing a relative by default... I normally add this flag:

durable_object_fetch_allows_relative_url

not sure how you do that with pages though

Compat flags can be set in the pages dashboard for production, and with cli flags for local dev

I'll find out the answer to this soon enough by pushing to prod for testing once I clean up a few other things, but will the beggining get stripped off in prod also?

You are correct, it does pass then entire thing in. I mis-interpreted because my code is using url.pathname, which strips it off. That said, request.url doesn't match what I put in so it's still replaced.

@HardAtWork , I owe you a beer! Thanks!!!

Really weird. What do you get if you just

console.log(request.url)

, without any formatting?

Is there any possibility of data loss with DOs? This is the first time I'm thinking of non-db backed storage, ie relying only on the DOs as the storage layer for micro services. In other words, as long as I'm using persistent storage, would any error condition (overloaded, reset, timeout etc https://developers.cloudflare.com/workers/learning/using-durable-objects/#common-errors) ever affect that?

Yes, there is, along with any other storage system. There is always a chance something can go wrong, whether an incident in a datacenter, or user error(accidentally running

deleteAll

). That said, DurableObjects are pretty well shielded from some of these issues. Every write is replicated across 3 datacenters, so in the event of any one of those datacenters going down, the object can be moved to another.

> A request unit is defined as 4 KB of data read or written. A request that writes or reads more than 4 KB will consume multiple units, for example, a 9 KB write will consume 3 write request units. (from https://developers.cloudflare.com/workers/platform/pricing/#durable-objects-storage-api) Are these units always calculated per-entry, even when calling

storage.put(entries)

? e.g. if I save 4 1kb entries in a single

.put

call, am I charged 1 or 4 write units?

Its per entry so it would be 4 writes:

Requests that hit the Durable Objects in-memory cache or that use the multi-key versions of get/put/delete methods are billed the same as if they were a normal, individual request for each key.

and the code to confirm 😛

thanks! really doesn't make writing small secondary index entries for large datasets very attractive

On Sunday I upgrade my account so I can get access to durable objects, I do not see the option to create one in the cloudflare portal or in wrangler2. Is there something I still need to do or I'm I missing something to get started with them.

You create them in your wrangler.toml, and then in the code you deploy

Ah okay thank you. I was thinking I could do it like kv. Thanks

https://developers.cloudflare.com/workers/learning/using-durable-objects/#error-durable-object-reset-because-its-code-was-updated '“Reset” in error messages refers to in-memory state. Any durable state that has already been successfully persisted via state.storage is not affected.' Are there other specifics you'd be concerned about?

Now that R2 is GA, it would be so nice to have a "backup DO storage to R2" that happens efficiently on the CF side. Right now any custom data cleanup or backup process competes with production readers/writers and slows everything down

hypothetically speaking if you had read-only access to storage from a different thread, would that help your backup process?

let's see, for backup yes! but not delete - also would still compete somewhat for cpu/request-queue i guess?

read-only nodes even for non-backup processes would be super nice assuming it at least allows a lot more requests for read routes and isnt super stale

worker wouldn't even necessarily have to be on the same physical node, if that's what you mean. point taken about deletes.

What would you use this for that decent cache interoperability wouldn't solve?