I try hard to design the DO parts of the
I try hard to design the DO parts of the system so that don't need any external fetches, mostly not for cost reasons but because it breaks the DO concurrency model. In the rare cases where I just couldn't design around that, I offload it to a Worker (sometimes through a Queue) who will "respond" by calling back to the DO when it has the answer. The "address" of the caller is passed along and used to get the "response" back to where it originated. JSON-RPC is really nice for this because it doesn't rely upon HTTP Request-Response. Rather it uses an id, so the "response" can come much later and be heavily interleaved with other "requests". You can do JSON-RPC all the way from the browser through multiple server-side hops (Browser to Worker to DO to Queue to Worker to ExternalService to DO and then back to Browser) over HTTP, WebSockets, or Cloudflare native RPC depending upon which is best for that particular hop. You don't pay for time in a browser that a Promise is unresolved, and this architecture essentially moves all of the waiting there.
6 Replies
For my edification, what part of the concurrency model breaks when external fetches are at play?
The Cloudflare Blog
Durable Objects: Easy, Fast, Correct — Choose three
When multiple clients access the same storage concurrently, race conditions abound. Durable Objects can make it easier. We recently rolled out improvements to Durable Objects that automatically correct many common race conditions while actually making your code faster.
I had to read that post maybe a half dozen times and have several clarifying conversations with Kenton before I fully understood all of the implications, but input gates open upon external fetches.
what i am building need to call apis, so that's why asking
Personally, I would not worry about the cost until you receive a surprising bill.
Thank you Larry for the input, much appreciated.