np, you probably already know that DOs are charged differently than regular workers: by wall time, n

np, you probably already know that DOs are charged differently than regular workers: by wall time, not cpu time. So if the DO in your example turned around and made another DO call or another network call, it will be charged for the entire time. So even though the code might look similar (or even be the same if you're using a shared library), the billing implications are different.

JJohn Spurlock np, you probably already know that DOs are charged differently than regular work...

iLearn•2/17/25, 6:48 PM

Thanks. I am aware of the wall time (for DO) vs cpu time (for Workers) based calculations.

IiLearn Is DO Compute Time also added to Parent Worker Compute Time ? Simple Use-Case :...

lambrospetrou•2/17/25, 6:49 PM

Q#1 : What is "billable compute" time for Worker ?
A#1 : (My Understanding) : Time_END - Time_START - 10ms

This is NOT correct. Since your worker was just waiting for the DO here it doesn't count as CPU time and shouldn't be billed.

Llambrospetrou > Q#1 : What is "billable compute" time for Worker ? > A#1 : (My Understanding) ...

John SpurlockOP•2/17/25, 6:49 PM

he's subtracting out the 10ms of waiting (is how I read this at least)

JJohn Spurlock he's subtracting out the 10ms of waiting (is how I read this at least)

lambrospetrou•2/17/25, 6:50 PM

Ah, in that case OK it's correct. I missed the subtraction for the 10ms and read it as equal.

Llambrospetrou Hey folks, I just released `durable-utils@0.3.0`: https://github.com/lambrospetr...

Fernando Barroso•2/17/25, 10:13 PM

This looks awesome. Question - do you think this could be used to horizontally scale storage for larger limits than 10GB? For example, I want to create an event store on durable objects, but the number of events will likely be > 10GB, so sharding sounds like a good idea.

However, I’m wondering if this would require custom logic if I want all events to be ordered across shards. This looks like it’s just hashing using the xxHash32 function which I think wouldn’t work for an ordering use case. Am I right? I’d prob have to add some ordering logic on top of that hashing function

FFernando Barroso This looks awesome. Question - do you think this could be used to horizontally s...

lambrospetrou•2/17/25, 11:00 PM

Yes, the goal of the sharding abstraction is to grow above the 10GB limit.
There are multiple approaches to handle ordering ontop of that. You could even have multiple levels of sharding, e.g. a tree of DO shards. The hash function needs to spread the load as much as possible to the shards.
The rest can be done ontop of that.

For example, a super simple approach is to bucket your events depending on your volume. Like buckets of 5 seconds. And then all events mapping to a 5s bucket are using the same partition key, so you have locality for those 5s to batch process all events of those seconds together. It depends on volume though of your application and specific needs.

Llambrospetrou Yes, the goal of the sharding abstraction is to grow above the 10GB limit. There...

Fernando Barroso•2/17/25, 11:36 PM

This is very interesting! Would you suggest using the StaticShardedDO as more of a “storage” layer and adding this global ordering type of logic on a class which extends this class?

Also, do you ever see a future possibility of making the # of shards dynamic? AKA scaling storage practically infinitely?

HowlOftheSun•2/18/25, 1:08 AM

is there a way to generate DO types so that workers that dont define the DO can take advantage of type hints in the ide?

HHowlOftheSun is there a way to generate DO types so that workers that dont define the DO can ...

hunt•2/18/25, 3:54 AM

do you mean if you're accessing the type through a binding? (i.e. worker A defines a DO that worker B is trying to access)

HowlOftheSun•2/18/25, 3:56 AM

Yep

hunt•2/18/25, 3:57 AM

I haven't seen a way to do that in a typegen fashion, but it can be solved by making a quick edit to the env object in the referencing worker

hunt•2/18/25, 3:57 AM

https://github.com/hntrl/durable-object-rpc-repro/blob/9804eccb6468db2d0363ca86aa1f1e96e63f7c63/packages/workerB/worker-configuration.d.ts#L4

hunt•2/18/25, 3:59 AM

(setting the type parameter of the Fetcher to whatever it is you're trying to access)

HowlOftheSun•2/18/25, 4:00 AM

Cool. It be interesting if the typegen could do it. I should probably just be more organized with my code

hunt•2/18/25, 4:12 AM

I actually made that repo for a different question I wanted to ask here: What's wrong with returning a durable object stub as an "rpc target" and accessing it in a different worker?

https://github.com/hntrl/durable-object-rpc-repro

my thinking would be that FooDurableObject would behave similarly to an RpcTarget where it can be returned from its parent worker, and I can access the methods on it from a service binding. If I try and do that though I get a message like Could not serialize object of type "DurableObject"Could not serialize object of type "DurableObject"

hunt•2/18/25, 4:13 AM

There's this section of the docs that would make me think this happens on its own: https://developers.cloudflare.com/workers/runtime-apis/rpc/#forwarding-rpc-stubs

Cloudflare Docs

Remote-procedure call (RPC) · Cloudflare Workers docs

The built-in, JavaScript-native RPC system built into Workers and Durable Objects.

Hhunt There's this section of the docs that would make me think this happens on its ow...

1984 Ford Laser•2/18/25, 4:30 AM

I believe that section on the docs is more general to Workers, and not specifically related to Durable Objects. An RpcTargetRpcTarget class will need to proxy function calls to required stub. In your example, BarRpcTargetBarRpcTarget needs to extend RpcTarget, and its constructor() should add the required stub which was already pulledby the instanced Worker, and also have class methods that will essentially call this.stub.func()this.stub.func() on the actual DO stub. Screenshot is an example of my implementation for RpcTargetRpcTarget

hunt•2/18/25, 4:52 AM

Gotcha. Thats a neat workaround! It seems kind of awkward to have to redefine a separate rpc target interface that has the same prototype as the object, but if that’s how it has to be then I’ll live

I included the bit on the docs (partially to correct my understanding) bc from what I understand I’d think that a DO stub and an instance of an rpc target are pretty much one in the same in terms of how rpc is orchestrated, so between workers they should behave the same. I also included the BarRpcTarget just to illustrate that “if both are considered RPC stubs, why would they be treated differently?”

hunt•2/18/25, 5:04 AM

The key difference would be that DO stubs are rpc targets to a completely different compute layer (RpcTarget stays on the executing worker) which is why I thought forwarding stubs was relevant here

FFernando Barroso This is very interesting! Would you suggest using the StaticShardedDO as more of...

lambrospetrou•2/18/25, 8:37 AM

adding this global ordering type of logic on a class which extends this class

Not sure if extending is the right thing, I usually prefer composition, so another class using the sharding abstraction as its storage layer and for localized queries. The outer class is mostly to orchestrate which shards to query and do potential aggregations if needed.

do you ever see a future possibility of making the # of shards dynamic? AKA scaling storage practically infinitely?

Absolutely. It's in my plans, but I want to find a nice API for it first. Dynamic shards need splitting and merging shards over time, so ideally we should provide some DO native hooks for it. Until those are built and published I want to experiment doing it ontop but needs some time.

11984 Ford Laser I believe that section on the docs is more general to Workers, and not specifica...

lambrospetrou•2/18/25, 8:41 AM

One change I would do here if I understand your classes, is that the RpcTarget should be created from the DO side, not the caller Worker side otherwise it's tied to the Worker's lifecycle. If the DO returns an RpcTarget then method calls on the RpcTarget are going to be executed in the DO itself.

For example having a method getRpcTarget()getRpcTarget() on your DO, and calling it from a Worker allows you to pass around that returned value and anyone calling it will go back to the DO.

1984 Ford Laser•2/18/25, 8:43 AM

Will that pin the DO to memory while the stub is being 'used'?

11984 Ford Laser Will that pin the DO to memory while the stub is being 'used'?

lambrospetrou•2/18/25, 8:44 AM

It's the same behavior as calling a method on it directly, so it will keep it alive yes as long as someone is calling something on it. It won't stay alive forever.

1984 Ford Laser•2/18/25, 9:42 AM

Is there a maximum number of tags that can be assigned by a DO acting as a Hibernatable server to different WebSockets? I know each client connection can have an array of up to 10 strings assigned to it, but if I have 1000 users who each had a unique tag when their connection was being accepted, could I theoretically target each unique user via that tag?

jed•2/18/25, 3:32 PM

I have a question about billing for the SQLite storage backend. Does a row written to a table with a materialized view count as:

1 write

1 + n writes (one for the original table, one per row in the materialized view)

Jjed I have a question about billing for the SQLite storage backend. Does a row writt...

lambrospetrou•2/18/25, 3:39 PM

Any row written counts yes. Not sure what you mean by materialized view, but each index update is charged for example.

jed•2/18/25, 3:43 PM

got it, thanks! so basically the same model as d1:

Indexes will add an additional written row when writes include the indexed column, as there are two rows written: one to the table itself, and one to the index.

(btw by materialized view i mean this: https://www.sqlite.org/lang_with.html#mathint)

quan•2/18/25, 5:32 PM

hi

I just have a question regarding durable objects and websocket together, can someone help to clarify

lets say we want multiple small chat rooms,

each chat room we could ensure to have an identifier that is unique from our end

so given we have this wrangler config

[[durable_objects.bindings]]
# This is the name of the binding that will be availble in our worker
name = "CHATROOM"
class_name = "Chatroom"

[[durable_objects.bindings]]
# This is the name of the binding that will be availble in our worker
name = "CHATROOM"
class_name = "Chatroom"

then we can initiate our first room as

const roomName1 = 'unique room name 1'
env.CHATROOM.idFromName(roomName1);

const roomName1 = 'unique room name 1'
env.CHATROOM.idFromName(roomName1);

then for another room we could do

const roomName2 = 'unique room name 2'
env.CHATROOM.idFromName(roomName2);

const roomName2 = 'unique room name 2'
env.CHATROOM.idFromName(roomName2);

and so on....

so in theory, given without any sharding logic, basically we can have as many as possible rooms, as long as we could just limit a single room into maybe less than 5k connections, or whatever the connection number that we feel like its safe?

scruffy•2/18/25, 9:12 PM

the DO storage docs (https://developers.cloudflare.com/durable-objects/api/storage-api/#methods) mention that you can use the KV API in sqlite-backed DOs... does that mean that it's possible to use list by prefix (https://developers.cloudflare.com/kv/api/list-keys/#list-by-prefix)?

Sscruffy the DO storage docs (https://developers.cloudflare.com/durable-objects/api/stora...

1984 Ford Laser•2/18/25, 9:24 PM

KV on DO operates the same regardless of the backend

1984 Ford Laser•2/18/25, 9:24 PM

So yes, you can list({prefix: 'pre-')list({prefix: 'pre-')

scruffy•2/18/25, 9:34 PM

excellent, thanks!

11984 Ford Laser KV on DO operates the same regardless of the backend

scruffy•2/18/25, 9:41 PM

sorry for confusion... the KV API says that

list()

list()

order is always lexicographical and there's no way to limit the list, but there's also https://developers.cloudflare.com/durable-objects/api/storage-api/#list which includes options such as

limit

limit

and reversereverse ...can these all be used together with list({prefix: 'pre-')list({prefix: 'pre-') from the KV API?

Sscruffy sorry for confusion... the KV API says that `list()` order is always lexicograph...

1984 Ford Laser•2/18/25, 9:42 PM

Yes. Ignore the Workers KV page when working with DO KV

11984 Ford Laser Yes. Ignore the Workers KV page when working with DO KV

scruffy•2/18/25, 9:44 PM

will do! thanks

1984 Ford Laser•2/18/25, 9:45 PM

They both work the same more or less, except that

list()

list()

in DO KV returns the K:V pairs, whereas Workers KV only returns the key names (can Workers KV be changed to align with DO KV?? This is such a weird distinction between the two)

scruffy•2/18/25, 9:48 PM

at least it's that way round rather than the other

1984 Ford Laser•2/18/25, 9:49 PM

I also wish writes on SQLite DOs weren't 1000x more expensive than reads

scruffy•2/18/25, 10:07 PM

Not sure where better to ask this question, so apologies if it's in the wrong place... I know that the default account limit for storage is 50GB and that it can be extended by using the Limit Increase Request Form, but does anyone have any idea of any ballpark "come on now, we're definitely not giving you any more storage" limits? also, has anyone used the form and have any stories about how quick the turnaround was? (I'm still scarred on both counts from experiences with Google Cloud Platform's quota request shenanigans)

Llambrospetrou One change I would do here if I understand your classes, is that the RpcTarget s...

hunt•2/18/25, 10:24 PM

my implementation of this in case anyone is curious

hunt•2/18/25, 10:29 PM

is there a reason we have to do this instead of using the DO stub as if it were an rpc target? from the docs:

By writing a Durable Object class which inherits from the built-in type DurableObject, public methods on the Durable Objects class are exposed as RPC methods, which you can call using a DurableObjectStub from a Worker.

Sscruffy Not sure where better to ask this question, so apologies if it's in the wrong pl...

hunt•2/18/25, 10:30 PM

also am curious about this, can definitely sympathize with the PTSD

hunt•2/18/25, 10:32 PM

I know cloudflare is better than most about accommodating limit requests. I've seen a 1-2 week on turnaround from them when requesting increases on other products (not sure on DO specifically though)

Hhunt I know cloudflare is better than most about accommodating limit requests. I've s...

1984 Ford Laser•2/18/25, 10:57 PM

What limits have you increased, and to what new limit (if you're allowed to talk about specifics)? I haven't needed to yet, but want to make sure I'll be covered in the future

Hhunt is there a reason we have to do this instead of using the DO stub as if it were ...

1984 Ford Laser•2/18/25, 10:59 PM

That doc note is mostly just to define the basic way that a stub is accessed after it is initialised. The reasoning for needing RpcTarget is to do with DO stubs on their own not being serializable, but RpcTarget is

11984 Ford Laser What limits have you increased, and to what new limit (if you're allowed to talk...

hunt•2/18/25, 11:03 PM

worker size & num of workers are the ones that are top of mind (I think we got a 5x increase?)

Hhunt my implementation of this in case anyone is curious

hunt•2/19/25, 3:06 AM

a continuation on my fact finding mission:

Returning an RpcTarget from a WorkerEntrypoint shows `never` for method return types

(this isn't really a durable objects problem and more of an "rpc types" problem so I'm taking it there)

Frank•2/20/25, 1:44 AM

we needed to delete a DO from our stack today. removed binding from wrangler.ymlwrangler.yml and added a deleted_classesdeleted_classes migration, but it still complained about worker binding not removed.
ended up having to remove it from CF dashboard, then redeploy from wrangler

Frank•2/20/25, 1:44 AM

is this expected

np, you probably already know that DOs are charged differently than regular workers: by wall time, n

Similar Threads

Similar Threads

Similar Threads