|
|
|
|
|
by neftaly
898 days ago
|
|
R2 was used because it was the only database-like service CF offered at the time. IIRC the P2pcf client polls the worker for new peers. Pubsub would let you use an ongoing websockets connection, plus all the channel management logic is built-in. The game-changer is that they've said they'll charge per-message as opposed to per-connection-second, unlike everyone else! |
|
DO/D2 will likely perform better than R2 unless you’re storing everything in the metadata. KV will perform better than all of them although if the storage is to keep a list of peers the API as exists today won’t work well for that - you’ll have to do 1 key per connection and retrieve via a paged list - otherwise you can lose clients since KV has no mechanism to do durable updates of values stored within keys*. You could also do DO with background refresh of cache to maintain good performance while maintaining better bounds on how long a value stays in the cache.
* actually it is possible if you mediate updates to KV through a DO (with storage as the ground truth or without it and risk occasional lost writes if the CF infrastructure decides to kill and reset/relocate your DO).