high runtime fees

[martinkallstrom]

Loving this project, thanks for publishing!

Have you found a way around this issue? https://github.com/drifting-in-space/y-sweet/issues/203

[naporin0624]

No specific workaround is known. One thing I can say is that you should use HibernationAPI.

I am getting more requests than are covered in https://github.com/drifting-in-space/y-sweet/issues/203, but the connection time has not increased to this point.

I will respond to what I know about what is being discussed in this issue

• The odd usage time of DurableObjects
• The cost savings of using the Hibernation API
• Duration time even after WebSocket closes

DurableObjects' odd usage time

Here is the LastWeek usage of my public https://yjs.napochaan.dev.

What you can save money by using Hibernation API.

If you prefer, use state.acceptWebSocket() instead, which will stop incurring duration charges once all event handlers finish running.

https://developers.cloudflare.com/durable-objects/platform/pricing/#billing-metrics:~:text=If%20you%20prefer%2C%20use%20state.acceptWebSocket()%20instead%2C%20which%20will%20stop%20incurring%20duration%20charges%20once%20all%20event%20handlers%20finish%20running

It is described like this. y-durableobjects supports Hibernation API, so it is less expensive than y-sweet.

Duration time even after WebSocket is closed.

In my environment the connection appears to be closed. It may happen when Hibernation API is not used.

DurableObjects billing documentation

See here https://developers.cloudflare.com/durable-objects/platform/pricing/#durable-objects-billing-examples

Examples 2, 3 and 4 are very expensive. The number of people using the system and the amount of time they are connected may lead to high bills.

[naporin0624]

I had no knowledge of DurableObjects' high billing. I have not applied y-durableobjects to production, so this kind of input is very helpful.