Which brings back the stuff I discussed about the 32kb value limit

If your docs get that big you might have to write some code to split them into multiple keys (there isn't a limit of total storage in the object), or you could in theory persist them to KV and use the DO for websocket coordination

Anyone got Typescript types for

new WebSocketPair();

in durable objects?

To be clear, I do not need to persist the YJS Document (binary) data to a KV. I just need it to be active in memory on the worker as long as there is at least 1 active websocket connection to the worker. Once the last connection drops, I will be writing the doc to Postgres via my own API. Can the durable object store ~10MB in state while 1 websocket is active?

oh I see

just some info on the latest state?

they can store 10MB in state but it has to be spread across hundreds of values

oh sorry

yes

I just got the chat application deployed, so Im gonna try changing it out to my YJS server now!

I think they are regular workers in terms of their limit of memory (512MB afaik)

thats great!

but the persistent storage is a key/value store with a maximum of 32KB per value

yup that makes sense. We may leverage a KV store for other stuff, but its not necessary for the primary use case: When 1 or more document editors have an open websocket connection, they are all guaranteed to connect to the same durable object instance which has a YJS doc (a

new Y.Doc()

) in memory

where do you see 512 MB RAM? The limits page lists 128 MB.

ah my bad

I guess its 128MB

We could certainly shard our docs in a way that limits each durable object to a max of 10 docs - 12.8MB per doc with some wiggle room is plenty

good use case for the KV store 🙂

Any idea how we could estimate pricing for that use case?

well

its $0.20/GB

but id say... it depends?

OK I've hit a roadblock as the framework I'm working with expects a

ws

websocket object and I'm not sure how to create that based on the

WebSocket

instance available in the worker

https://github.com/cloudflare/workers-types/issues/84 It's helpful to also add your bindings:

type WorkerEnv = {
        foo: DurableObjectNamespace;
        bar: KVNamespace;
    }

that did the trick! did you find/make a base DO class, such as

// types DurableObject & DurableObjectState are from '@cloudflare/workers-types'

class BaseDurableObject extends DurableObject {
  constructor(controller: DurableObjectState, env: WorkerEnv) {}
}

yes, like that, although you'd have to do

implements DurableObject

since it's an interface, not a class

Are binary messages in DO websockets really unsupported? Or is it just the docs that are wrong?

Is it possible in your setup to encode it as a string and decode it on the other end?