Ah perfect! That's exactly what I was looking for

Thanks @Unsmart | Tech debt!

Would something like this be feasible to make the pricing for websockets scale with the number of events and not idle duration? Rather than having a DO deal with websocket objects, terminate the WS within the infrastructure. Provide an API for handling events from a WS, iterating over the currently active sessions, sending messages etc. This would allow the DO to be unloaded without losing WS connections. I realize I'm unlikely to have invented something the team hasn't considered already.

They already have plans to possibly not bill idle time with websockets: https://discord.com/channels/595317990191398933/1069672593898086472/1069672596817317908

Thanks for the link!

Are there any blogposts or videos by Cloudflare or the community about handling concurrency within DurableObjects when you want to handle it yourself for higher throughput

If you are thinking of using

allowConcurrency: true

, you can use explicit transactions for writes but you'll still need to worry about in-memory state. The only other thing I can think of that might be a gotcha is that you could start a write operation that uses transactions, then one or more read-only requests come in, those read-only operations won't see the pending write operations. Do you have some evidence that it will make a big difference in performance? The more I think about it, the less I believe it would help much if any. Remember, there is only ever one instance of a particular DO. You get more throughput by having more DOs... or is that what you are thinking?

Thank you. No, I don’t have evidence, but JavaScript works well for io heavy use-cases because it can handle concurrency well. I’ll check out the transaction code and be careful with in-memory state.

For

allowConcurrency: true

if the cache hit rate is high, I don't think you'll see a big throughput gain. One more thought, you might also play with

allowUnconfirmed: true

for writes if you can live with the risk of a failure effecting later reads. I say "effecting later reads" because I believe you will get an error for the write that fails. Regarless, if you create any benchmarks on the potential throughput increase, I suspect many folks here would like to hear about it.

Don't know why binding can't be created.

Probably wrong wrangler format?

Also tried exported both classes in the same export without any success

Using the latest wrangler (2.15.0) and compatibility date (2023-04-11)

Migrations where the problem.

toml
[[migrations]]
tag = "v1"
new_classes = ["MinecraftVoteDO"]

[[migrations]]
tag = "v2"
new_classes = ["DiscordVoteDO"]

this fixed the issue.

guys, is it good practice to use a durable object for objects like user, post? Let's say I'm doing a Twitter counterpart where each user and tweet is a separate durable object

I probably wouldn’t recommend using them for that. I don’t see any benefits in this context over D1 or KV

@Dio DOs are usually faster than D1, since D1 is DO+SQLite, and KV is eventually consistent, which isn't ideal for atomic ops like like counting. Maybe you could use DOs for writes, and KV for reads?

the disadvantage is that it's more expensive than a kv? Or is there some other disadvantage why you wouldn't do it?

I'm just looking into it all. I apologise if my question is stupid

i can, but it kind of complicates the code?. Why not just use DO? really wonder what the disadvantages of this approach might be

While DOs are awesome for applications that require atomicity, they struggle at scale(at least inside a single DO). When you hit 100+rps, your DO may struggle to process requests in a timely manner, and may even begin to drop requests, which is why it is good to use them only for writes.

thanks. hmmm I was thinking of making a simple multiplayer game with about 30 rps (requests per second). Does it turn out to be impossible?

Is that 30 rps per client, or 30 rps overall?

per client

here you are talking about request in overall?

If you can structure your app in a way that no DO has more than ~100 rps, then it should be fine