Yeah I meant more the input/output gates thing

Do you have any plans to write about patterns for dealing with websockets? E.g. maintaining connection state, what sorts of error/failure situations to handle (this is the big unknown for me)?

Sorry, I'm exploring pub-sub with the websocket javascript client rather than durable object's websocket support because I eventually need pub-sub functionality anyway.

I was also leaning in that direction

Ok, maybe once I've done some experiments I'll reach out and see if you're interested in a guest post 😉

why did you choose medium? asking out of curiosity. and of course huge thanks for starting to write more on DO

I definitely want guest posts!

Not a conscious decision. I have posted there before.

No plans, what would your use case be?

Transactional storage's put and delete functions support up to 128 keys at a time. But what if I loop over them without using await over 128 times (taking advantage of automatic write coalescing). Is that going to run into the same limit? Do I need to await at least once every 128 operations?

see "Write buffer behavior" under https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#transactional-storage-api not a 128 key limit per se, but if you're doing enough writes that memory is a concern you'll want to await

To separate creation vs usage - have privileged access via the CF APIs from the backend for creation, while not allowing such a path for normal usage operation via the worker.

I have two

durable_objects

bindings as

User

and

Group

. Is there a way to index or filter to get all the User in a Group without putting them in

Group

object?

export class Group implements DurableObject {
state: DurableObjectState;
app: Hono = new Hono();
users: Record<string, User> = {};

if you want a Group object to know about User objects, you'll have to put that info in. The only indexing built in to Durable objects is by name/id for the object, then by key for storage within that object

Hmm, right. So let’s say I add the groupId in the User object. How do I fetch all the user using the groupid ? Is there an example I can follow or I can read about?

I am playing around with key. ${groupId}:${userId}

you'll have to write data the way you want to query it. So if given a group you want to know all users in that group, and you have a DO named for the group, you'd want to store users in that DO for the group. If it's not a lot of users, you may be able to just stick them in an array under a storage key named e.g. "users". If it's potentially a lot of users, store under a key per user with some naming convention (e.g. keys starting with "user") that allows you to use state.storage.list with appropriate start / end / limit parameters

Gotcha! Helped a lot. One last thing, Lets say I have

User

object

export class User implements DurableObject {
state: DurableObjectState;
data: {}
}

I could store data like so

await this.state.storage?.put("userData", {        ...userData,      });

or

this.data = userData;

When to use which one? advantages and disadvantages?

If you use

this.data = userData

, you won't get the persistence of putting it in storage

I.e. when the DO ends, it's evicted

what do you mean by

DO ends

?

When your DO stops processing tasks or requests, after a short period it'll stop running

oh right! Got it, thanks 🙂

waitUntil

is technically available as a member of the first arg to the DO constructor https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#durable-object-class-definition but as mentioned there and here, it's not really necessary in DOs

Thanks!

Hey all, similar to the above convo, I'm trying to use

this.state.blockConcurrencyWhile

in a DurableObject constructor to set up instance variables. The docs, and types specify that this should be an available function, however actually calling this function throws an unhandled error

(node:79350) UnhandledPromiseRejectionWarning: TypeError: this.state.blockConcurrencyWhile is not a function

. Anyone familiar with this?

I suspect this might actually be an issue with miniflare

Just to make sure, have you assigned this.state to the state passed into the constructor?

Won't help you fix this problem but I use a lazy hydration approach that avoids this problem. I've written it up here just now for you: https://medium.com/cloudflare-durable-objects-design-patterns/lazy-hydration-cab27e7c70b5

I forget, is there a way to derive the locationHint from an already-created DO?