I'd like to add support for request formats other than

fetch()

, but we're sticking with

fetch()

for now mostly to avoid having to spend a lot of time thinking about exactly what we want here. Personally, I'm hoping to add some sort of direct Cap'n Proto support, since under the hood all the communication is actually over Cap'n Proto, not HTTP.

I imagine we'll also consider something where we just use "structured clone" serialization to let you send arbitrary values, without having to worry about serialization

but yeah, this is all still undecided

That would be ideal. But I totally understand that it's not a priority, since it can be quick easily worked around with these wrappers.

In the "limitations of the beta" section of the docs, one thing that's listed is the inability to access a DO (or KV) from a DO. Is that something that's eventually planned? I could easily foresee a usecase where you want to store a reference to a >32KB object being held in KV, from a DO.

eh? If the doc says that, it's wrong...

durable objects have always been able to talk to each other -- the chat demo uses this. And KV is perfectly accessible from DO as well...

Oh, I might have misunderstood it? It's that a DO can't access another DO's storage not another DO just in general. https://developers.cloudflare.com/workers/learning/using-durable-objects#cross-object-storage-access

ahhh

... hmm, that's weird that that's listed as a beta limitation, since it's inherent to the design of durable objects and is not something we'd change later.

Is there anything else listed there that won't be removed as a limitation post-beta?

no, the other points all look like things we're working to fix

Amazing! Well, I had a lot of fun trying stuff out today, so my kudos to you and the team for building such cool stuff! 🧡

(and thanks for answering all my questions!)

thanks for the feedback!

I've tried this with a non home server as well so 100% sure its not my connection

docs update: https://github.com/cloudflare/cloudflare-docs/pull/746

Sorry that debugging is really difficult right now. We really need to come up with some sort of preview support so that you can iterate without pushing and waiting 30 seconds, and so you can console.log() and see uncaught exceptions. Preview with durable objects is a surprisingly hard problem though... we're working on it.

is there anything you can think of that would get me disconnected?

is it the overly large volumes of data im sending, ~15kbps

max at 30kbps

it trips out the more data i send through, im not storing anything through its just send to ws subscribers

My guess would be that you are not getting disconnected, but the code is somehow failing to handle messages, and the exceptions aren't being reported anywhere so it's hard to tell what's happening

i thought it was that, i added an error hook. So i connect in with another websocket and add a 'listener', and now if another socket has an error it sends a message to the listener

but i dont get anything on that

is webSocket.send blocking (does it need to be await webSocket.send)?

the error hook reports connection errors, but it doesn't report when your message handler threw an exception

i modified it in the latest git

No, you don't need to await `send()`s

so i do a try catch and send the message to the socket with {debug: true} (the one set by a listener)