Might be me completely misreading this, but would this library allow you to interact with DOs with something other than fetch?

the initial entry is via

fetch()

but there are some abstractions in there that allow for non-

fetch()

communication

if you wanna poke around, msg me and i'll send you the stuff

I do think that I have exactly that problem. I have two (or more) DO that need to work together!

One have the raw data, and the others have the processed data. And everytime I update one I need to update the others.

If I perform a fetch request to a durable object from a worker, and said durable object performed a read from its storage and returns this to worker. Then would the pricing be as follows? $0.15 per million requests to worker, $0.15 per million requests to durable object, $0.20 per million requests to durable object storage (read), So for this workload it would cost $0.35 per million requests (on the durable object side) and then a further $0.15 per million requests on the worker side. I have excluded compute costs from this calculation as that is dependant on implementation. The reason I ask this is I was reading a Cloudflare blog on durable objects saying that they were cheaper than DynamoDB, but even just from the durable object side, they would work out more expensive because of the additional request cost to the durable object. The only way I see them being cheaper is repeated storage operations per durable object request? Even if you work out each durable object read storage request, that is still more expensive than DynamoDB ($0.20 durable object storage read per million, $0.15 dynamo db read per million, both 4KB) Have I missed something? Thanks.

Wait what?! You promised I would get to have a look at it before you send it out to the Discord community! Don't you love me anymore? Or just the Discord community more than me?

lol sorry, i still do 😛 just forgot tbh. lot of names but didnt write them all down

dm'ing now

hi! Are there collections of patterns for durable objects yet? I'm trying to work out how to best convert my existing application but I realise I'm probably thinking about durable objects incorrectly.

It isn’t yet super clear how you should use them, but it is pretty clear how you shouldn’t use them. And take relational database pattern is certainly not what you need. I personally like to think about them like DDD aggregates. https://martinfowler.com/bliki/DDD_Aggregate.html

@User here's the right spot

but yeah, I can see where your DO is with that

cheers. I'm connected to

43fce291c00c55cba840abb1af0740c038cbf94d07976f7dd355080500a3a3dd

and it's exhibiting the behavior described

@User can you fetch other URLs fine?

(from within the DO)

The DO makes another request to Discord that works as expected

I can modify it to test other endpoints if you'd like me to poke it some more

does

http://example.com/

work?

This is manifesting on a service that is semi-live, I can also provide plenty more DO id's for investigation I imagine they may be in other locations? I will try requesting to

http://example.com

and report back in a few min.

👍 Also interested to see if the problem goes away after you update your code

Interesting! The logs would suggest that

http://example.com

is failing as well. Here is what I did, and here are the resulting logs.

typescript
 console.log('Requesting example dot com')
  try {
    await fetch('http://example.com')
  } catch (e) {
    // @ts-ignore
    console.log('Error fetching example.com', e.message)
    throw e
  }
 console.log('Fetched example dot com')

logs": [
    {
      "message": [
        "handling queued video",
        {
          "type": "queue",
          "videoId": "Rj-m1ploAys"
        }
      ],
      "level": "log",
      "timestamp": 1631229159271
    },
    {
      "message": [
        "Requesting example dot com"
      ],
      "level": "log",
      "timestamp": 1631229159271
    },
    {
      "message": [
        "Error fetching example.com",
        "Network connection lost."
      ],
      "level": "log",
      "timestamp": 1631229205273
    }
  ]

I dont know if this is relevant or not, but this fetch is inititated after an incoming websocket message (

websocket.addEventListener('message', () => {})

) to the DO, whereas the fetch that "succeeds" is part of the DO

fetch

handler

I am going to add a fetch to

http://example.com

in the

fetch

handler path as well, and see if it then succeeds?

Update: It fails in the

fetch

path as well

is your DO opening websocket connections, acting as a client?

The DO is opening websocket connections in

fetch()

const pair = new WebSocketPair();
const serverSocket = pair[1];
const clientSocket = pair[0];

returning the

clientSocket

in

return new Response(null, { status: 101, webSocket: clientSocket });

is that new, and things worked before? workers (including DOs) have a limit of 6 concurrent subrequests — I’m not sure that’s whats happening here yet, as last I recall requests over the limit would block and not return an error

This was coded up about 6 months ago and I haven't paid attention to it much. It's been working until today, in a decently high capacity. No changes were made in this script for months.

are all of your DOs hitting this problem, or only some