[neftaly]

I evaluated using this in prod, but came to the conclusion that R2 was a bit shaky as a database. CF has since come out with D1 SQL, DO (beware vendor lock-in), queues, and my favorite, MQTT pub-sub, which would be better options. They've also been teasing some vastly improved options for STUN/TURN; I wouldn't be surprised if more turnkey signalling popped up.

[vlovich123]

I don’t know what the consistency requirements are but workers Kv or r2 + cache might be smarter choices in terms of improving resilience and also performance by a lot (same goes for suggestions of using DO - R2 is kind of a weird choice to manage stateful rendezvous). Queues and pubsub feel like incorrect choices unless I misunderstood what they’re using the storage for.

[gfodor]

Author here. KV did not provide the consistency guarantees needed for this to work. If you were signaling across two edge nodes, you didn't see candidates until the data was replicated, which took a long time. R2 doesn't have this problem.

[neftaly]

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!

[gfodor]

D1 looks like it could replace R2. Most of the tricky business in p2pcf is dealing with all the ICE details - porting the persistence from R2 to D1 might not be too bad.