^

Oh... perhaps the missing feature then is a deleteRange()?

You mean deleting many instances with one delete request? Makes sense, yes 🙂

actually

delete()

already lets you pass a list of keys to delete in a single call, though being able to specify a range (with the same syntax as list()) seems like it'd be a bit better in this case.

Awesome, I wasn't aware, this is a solution for our use case then, because we should know all IDs.

in order to implement an "append" operation on a single key's value we'd probably have to read-modify-write under the hood anyway, I don't think we'd be able to do anything clever.

OK yes, that makes sense. We'll try using separate instances and "multi delete" then, thanks again for the suggestion!

@kenton, does a send() to a queue open the input gate for a DO?

@kenton or anyone here, is there a way to directly use from our own code the structuredClone serialization you use in DOs and Queues? node.js now has v8.serialize(). Might we be able to use that? or are you using Cap'n Proto internally instead of the V8's own serialization?

BTW, right now, I use cbor-x (which has support for structuredClone) as my primary Content-Type for Requests and Responses and I'm happy with it, but it is an additional dependency in my Pages Functions and Workers so I'm wondering if I can replace it with something native.

structuredClone() is available as a global

The v8 module will come to nodejs_compat eventually too

would love to see a

deleteRange

, though curious how too-long requests would be handled - exit early with progress? or run indefinitely and hope for the best like

deleteAll

: )

Sorry for the confusion. I use structuredClone() but I'm wondering about the serialization capability that Cloudflare uses to support all types supported by the structuredClone algorithm.

They just use structuredClone from V8

Or rather, they all end up at the same point. Queues (https://github.com/cloudflare/workerd/blob/ed865f47ad6566916cb9620a0dd223d797f420ee/src/workerd/api/queue.c%2B%2B#L14-L21) and DO Storage (https://github.com/cloudflare/workerd/blob/ed865f47ad6566916cb9620a0dd223d797f420ee/src/workerd/api/actor-state.c%2B%2B#L726-L734) both call

of which, you access that via the

structuredClone

global ()

If I want to bind a DO to a Pages Function, do I still need a separate Worker definition? Even if I want to call the DO directly from the Pages Function?

You do

Yes, writing to a queue is considered external I/O. It would certainly be interesting to consider changing this to treat it more like a storage write someday, though there's a bunch of stuff we'd need to consider to make that happen. Keep in mind you can use blockConcurrencyWhile() to explicitly keep the input gate closed if you want.

We use V8 serialization, but we're cautious about exposing it. Chrome does not expose serialization to applications, despite using it internally similar to how we do. My concern is that the serialization code may not have been subject to the same adversarial security research as the rest of V8. Also, V8 serialization is not forward-compatible: an old program may not be able to parse data serialized by a new one. Within the Workers platform, we can account for this because we know when ALL instances of the runtime have been updated to understand a new version, and thus it can start being used. But if applications were to expect compatibility between V8 serialization on Workers vs. Node, there might be problems where suddenly your Node code stops recognizing the values coming from your Worker. Hence I think it's best for V8 serialization be encapsulated within a system, not sent between independent entities on the internet.

I'd expect it to work similarly to deleteAll(). That said, deleteAll() gets surprisingly ugly under the hood. Could be challenging.

Is there any chance there will be support for V8 (De)Serialization for internal communications(Service Bindings, DOs, Queues, etc.)? I get that handling Worker-to-client compatibility would probably be a nightmare, but on-platform communications should be a bit easier to account for, no?

Yes, I would like to support it for that. I think queues already do? But I agree it would be useful for service bindings and DO communications as well. We need a better story than HTTP there (especially as it isn't even HTTP under the hood anyway...).

Ooh, didn't notice Queues had that! Nice!

In that case, can the Worker basically be a dummy

return new Response('hello world!');

kind of thing? Does its implementation come into play at all if I bind the DO to a separate Pages Function?

You can just export the durable object, you don't need to export a regular handler iirc

Ah, gotcha. I was exporting the class definition, but not as default. exporting as default fixed the error I was seeing about using ServiceWorker syntax

btw if you use

itty-durable

in production you might want to apply this patch 🙂 https://github.com/kwhitley/itty-durable/compare/v1.x...sathoro:itty-durable:v1.x#diff-97a933af0fb78f328d569be08bd44008f49fcffac639b9a9aaf37e114b346a2d we were getting quite a few intermittent errors in production

this was a new one for us