Here's a doc that explains it

The URL can be anything

well, any valid url that is

Yup. The trick there is that no one else has access to

env.DURABLE_OBJECT

like you do, so they can't send any request to it.

alright thanks, ill give it a try

That fixes it, thanks a lot! 🙂

as @User pointed out, awaiting the response body of the fetch fixes this, but we're working on decoupling console.logs from request termination to improve the experience of using

wrangler tail

with DOs that often have very long-lived requests

nice - would this include ws requests as well? Getting all of the logs after the fact is... less than ideal : )

yes

I actually noticed that Cloudflare changes it to: https://fake-host/cron/calculate-usage

if you fetch('/cron/calculate-usage') for example, it will become: https://fake-host/cron/calculate-usage

Yes, you can use that space for yourself too, by including a useful fake hostname, e.g.

https://<durable-object-class>-<durable-object-name>-<version>/cron/calculate

, a way to surface more info in

tail

etc

thats useful, thanks for the tip

Im wondering how others would approach this problem. Lets say you have a analytics tool running on DO that tracks pageviews. The customer is billed based on the amount of pageviews and I would like to send an email if a user passes for example 80% of the limit of their plan. Would you write another usage total to workers, which would double the cost of running the DO. Or maybe run a CRON that calculates it once per day?

I cant think of any other way

Adrionally, you can also specify a custom protocol. So the Durable Object Transfer Protocol

dotp://

is very real 😛

I think custom methods are possible as well iirc

Hi - Is it possible to bind a Durable Object to multiple workers and thus access the same object from instances of different worker scripts?

Yep, it's just a do namespace binding in all client workers, you can even call them from the older non-module script workers

If you're using

wrangler

you can create cross-script bindings in the

durable_objects

section by adding a

script

entry to the binding, see https://developers.cloudflare.com/workers/learning/using-durable-objects#configuring-durable-object-bindings

Thanks, got it working! I had tried this some time ago but didn't put the

script_name

value right at the time. It is not obvious from the documentation that script_name is the name of the worker that published the DO class and not the name of the script containing the actual DO code.

Any word on if we’ll get an expire / ttl option for

storage.put

?

I use durable objects quite frequently for short lived tokens but having to keep track of flushing out old tokens doesn’t feel great when KV has such a nice simple API for that already.

Not exactly that, but we're working on making it possible to schedule future callbacks to a DO, which you could use to build that.

Is there an easy way to send a cron directly to a DO? Seems like a waste to spin up a regular isolate just to call the DO, if you do scheduled workloads.

Wait what? I was just trying to figure out if this is possible. Is this documented somewhere?

Here, but is pretty vague IMO: https://developers.cloudflare.com/workers/learning/using-durable-objects#configuring-durable-object-bindings

Hi, @User ! We added Rollup. It's much better now. We have to keep external resources at the top level though, but it's okay for now. Thank you! 🙂

(at the top level in dist)

Nice! A fix to the original problem was found, likely will be released sometime next week I’d keep using a bundler though, gives you more room for code/dependencies