napolab
high runtime fees
Loving this project, thanks for publishing!
Have you found a way around this issue? https://github.com/drifting-in-space/y-sweet/issues/203
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.
I had no knowledge of DurableObjects' high billing. I have not applied y-durableobjects to production, so this kind of input is very helpful.