There are three tiers.

wrangler

is the CLI,

miniflare

is the system that actually mocks a Workers environment, and

workerd

, if you choose to use it, is the actual Workers runtime.

is there like a framework on top of do that can handle spinning of new do instances when limits are reached? I want to save json objects inside of DO to be quickly available during requests. If I want to store like couple 1000 of json objects inside one DO (one do per client). Would I store everything in one object like this.configs = {} or is there a more efficient way of doing it?

So… getting DO to work with Pages just needs two CLI flags, but getting DO to work with Workers need an entire workerd installation? That can’t be right… Is there really no tutorial or example available for this? D:

No, I was just explaining what the different parts did. To use a DO with Workers, all you need is a

wrangler.toml

"We do plan on improving the lifecycle management of objects soon, and auto-expiration is very likely to be part of that." saw this in a forum post from 2 years ago, did anything happen on this front?

Can you link the post in question?

I guess this was before alarms

And now alarms are basically the tool for all lifecycle related things?

This is probably the answer, from the thread: > You can build a TTL using alarms. Whenever your object is accessed, you would use

setAlarm()

to set the alarm time to

Date.now() + timeout

. There is only one alarm per object, so each call to

setAlarm()

replaces the previous alarm with the new alarm time. When that time is reached, the alarm handler will be invoked. In your

alarm

handler, you would use

storage.deleteAll()

to delete your object. > > Since it’s possible to build TTL using alarms, we probably won’t be adding a separate TTL feature. - Kenton

Ah well spotted

I guess better that energy is put towards stuff that can't be done in user land

Can someone help me with this one? Please 🥹

I don't think you provided enough details to make a full diagnosis and even if you did, I have no experience with queues and I'm far from knowing all the ins and outs of DO performance. One wild ass guess though... do you use

env.MY_DO_NAMESPACE.idFromName(name)

? Those require a global lookup on object creation and should be avoided.

oh ya, that could be it. I am using

idFromName

. Changing that to id, that would show significant change I guess?

https://github.com/topics/durable-objects I think there should be an awesome-durable-objects repo 😁

just found this too https://github.com/ticket-bridge/hyper-durable

the extra layer of abstraction it proposes makes my head hurt though

Hello again. I am still unable to figure out how to do this. It's not very clear in the documentation. :/

https://miniflare.dev/core/mount#durable-objects Does this help?

It does not help, unfortunately. Am I supposed to run Miniflare separately from Wrangler?

https://discord.com/channels/595317990191398933/773219443911819284/1069328319314677830 Found this To be honest I haven't tried using multiple workers myself 😅 Generally I just use miniflare directly but I haven't checked the new wrangler out in so long

Ah, it's not linking correctly. Here's his message

It looks like environment property isn't optional judging from that conversation

Hey, I solved it! I learned that "script_name" in Worker A's DO binding should be the "name" in Worker B's wrangler.toml-file. So I removed the Miniflare stuff, and made sure the names matched, which required a change from "session" to "sessions", and now it works, finally!

No environment property needed.

And of course the two workers must be up and running simultaneously, locally.

I'd like to say that the documentation on "script_name" is very bad, and it would be nice if someone could update the Durable Objects section to explain this better, giving the above solution for how to do a local binding to another / multiple workers.

Thanks for your help!

Is there a way to force a Durable object instance to live on a specific colo?