let me test redesinging my model and using cron to tick my DO

cuz i was using websockets that are connected to randomly process work for the other websockets connected (like to send keepalives)

logger very appreciated, thanks devs

it seems I have a bugged cron trigger? I changed a 3min to a 1min cron trigger in (latest today) wrangler and deployed it. now i keep getting a 3 minute cron tick, i deleted the trigger manually from the cloudflare website, and still get it

could i delete the worker and redeploy from wrangler?

seems it finally autocorrected after deleting + adding it a few times using a combo of wrangler and the panel to do so

Shouldn't need to do it a few times

but it does take a few minutes to deploy

does the storage.list function return a Map in sorted order, like if I call map.entries, or map.keys, map.values are they in order ?

In practice, yes (

key

, and

entries

that is,

values

correspond to the sorted keys) And when you pass

reverse: true

, they iterate in reverse order

Cool, what do you mean by "in practise" is that guaranteed by the js api ?

Just verified that behavior in workers production with a quick test, but someone on the workers team would need to confirm any guarantees. They mention the ordering in their own docs, and iirc es6 maps iterate by insertion order, so cf can control it (unlike a java HashMap) https://developers.cloudflare.com/workers/runtime-apis/durable-objects

thanks @User ! read the docs but did not feel like it was a guarantee. But as you said, since with js you can ensure the order efficiently (insertion order), it is probably already a guarantee

Enjoying using Durable Objects but struggling to know what the best pattern is for lists. Let's say I have a bunch of User Durable Objects with lots of profile data in their storage. Each user has 100 friends stored as an array of ids: {id: '12af23', name: 'Kev' profile: { ... }, friends: ['3432', 'af123']} Problem is when I want to list friends in app I need to make 100 requests to other user objects to get their names. Promise.all(ids.map(id => this.env.user.fetch(

user/${id}

))) So I was thinking of storing the names in a central strings KV paired with ids. But KV API only allows you to get one key at a time it does not let you do env.NAMES.get([ ...ids ]). So this would still need 100 requests too (and KV requests are more expensive). I could store the name lookup in storage in a 'name' Durable Object. Look ups would be cheap as I could do a single this.state.storage.get([...ids]) and return 128 names at once. But because there can only be one instance of a Durable Object it creates a bottle neck which all users need to be squeezed through. I am not wanting to duplicate the names as cache invalidation is hard. What is the best way of handling these kind of list screens where you want to grab and display a name for all ids in an array?

Is there a good way to get all currently active DOs from a class?

You mean instances that are currently loaded into memory?

Yeah, or DOs in storage too.

Not currently. We're working on an analytics API that should support this (and a lot more) soon

Would that be accessible internally(From inside a Worker)?

It's an HTTP API so technically yes, but you wouldn't be able to hammer it, really

You could have your objects heartbeat some 'directory' DO, or keep a websocket open and remove them from the live list on disconnect, or something like that

Is locking a DO to a specific colo on the Roadmap?

Not that I know of other than Jurisdictions (we can add more if people request them): https://blog.cloudflare.com/supporting-jurisdictional-restrictions-for-durable-objects/

Colos can be temporarily disabled and traffic re-routed elsewhere so locking to one colo would probably not be desirable

By region/continent then?

Is this for compliance or performance or what?

Performance.

Well I can't speak to the roadmap but I imagine more control over object location will be something we offer eventually

is it fair to say the use-case for durable objects isn't a replacement for a traditional core db with relationships between data? It seems like any time you need to query relationships between datasets it only really works if you really carefully name your data keys to support this

The way around that is to denormalize your data and duplicate it onto central DOs where it makes sense for your usage pattern. It makes updates a little more cumbersome since you might have to update indexes in several places, but that's how I think of it. Store what you need on each DO for the queries you'll need to return from it, essentially.