https://discord.cloudflare.com logo
Join Discord
Powered by
# durable-objects
  • h
    That's a good idea. How would it handle getting prematurely shut down, though? Would there be a way to store a reference to a connection in Storage?
  • m
    The DO being shut down or the incoming stream of audio?
  • m
    I assume the chunks would be state.storage. The chunked stream itself would just stop when the manifest stopped being updated.
  • m
    (and there would have to be a cleanup mechanism to remove stale chunks and such)
  • e
    My first instinct would be for the rooms to be their own DO and the Lobby to be another. And the room DOs can update the Lobby DO as needed. Then depending on how many people would be in a lobby I would connect them straight to the DO, or go via something like KV
  • r
    Hmm yeah, that's very interesting. I keep hearing about 'performance issues', is it because all messages sent to a DO are processed synchronously?
  • r
    So if we have 10-20 rooms, where people are joining/leaving, it can't be that bad.
  • e
    It is scaling (per DO) issues. They are very horizontally scalable. At 10/20 rooms you’ll be fine!
  • r
    Ok super. Can't wait to experiment more with this!
  • m
    Hi, we are stuck at the same problem (Workers as a websocket client to DurableObject). How did you solve it?
  • i
    I think in the end it was a stupid mistake, I did a POST request with a body holding some information hoping that I'd get a websocket back but this shouldn't work and doesn't work according to the websocket standards. It should always be a GET request.
  • m
    So, switching to GET from a Worker sending an upgrade request to the DO worked?
  • i
    Yes
  • i
    I passed data through Headers instead of doing a POST request, you could also use URL params.
  • i
    Copy code
    ts
        const res = await chatroomStub.fetch(
          `http://chatroom/messageSend`,
          {
            method: 'GET',
            headers: headers,
          },
        )

        if (!res.webSocket) {
          throw new Error('No websockets found.')
        }

        res.webSocket.accept();
  • i
    I'm not sure if 
    .accept
    is necessary here, but this works now (this is script from the Worker)
  • i
    Make sure you send the WebSocket back to the Worker with statusCode 101. Here's the minimized version from the DO:
  • i
    Copy code
    ts
            // Start websocket server, send client back.
            const [client, server]: WebSocket[] = Object.values(
              new WebSocketPair(),
            )
            server.accept()

            // Do events on server here.

            return new Response(null, {
              webSocket: client,
              status: 101,
            });
  • m
    Thanks, but the code above is what we do, too, and: 1. Browser --- [websocket] --> Worker+DO (works in this case) 2. Worker --- [websocket] --> Worker+DO (does not work) Were you able to get websockets as in scenario #2 working?
  • i
    I'm not sure if I understand what you're trying to do. In Scenario #2, what is triggering your worker?
  • i
    Browser Worker Durable Object is how I got it working
  • i
    So there are actually 2 websocket connections, one from Browser to Worker, and one from Worker to Durable Object, and they are completely seperate, in my case the worker just proxies them though (and it could be multiple at the same time).
  • m
    The Worker itself is an originator of the WS request. What's triggering it could be a cron job or a REST call or a browser, but it doesn't forward websocket connections, but instead creates them to be sent to a Worker+DO
  • i
    Yes so like this right: Browser / Client Worker Durable Object
  • m
    Copy code
    {
  "webSocket": null,
  "url": "wss://abcdefghi.lmnopqrst.workers.dev/webSocket/createSocket",
  "redirected": false,
  "ok": false,
  "headers": {},
  "statusText": "Not Found",
  "status": 404,
  "bodyUsed": false,
  "body": {
    "locked": false
  }
}
  • m
    No matter what we do, this is the response from DO
  • i
    You are getting a 404 here so there is something wrong in your routing there.
  • i
    If in the same handler you just do 
    new Response("OK")
    it works?
  • m
    Not quite: Client / Browser --- [https] --> Worker --- [ws] --> DO
  • m
    The same code returns a websocket when a Browser is the originator of websocket requests (and worker is just proxying it through to a DO).
1...161162163...567Latest