Did a quick test, since before this I also used some very ad-heavy p2p solution, and I see similar issues there. Not sure if you're looking for feedback, but these were all issues I considered before settling on a server-based HTMX long-interrupted-polling approach, which if you think about having server + client + realtime-ish features in the context of "just htmx" + tiny LoC is pretty cool (well I think it's pretty cool :D)
In the WebRTC p2p approach, without some sort of sync protocol that validates the state of data:
- the host must be online / already there to join a room; the host leaving the room means everyone gets kicked!
- if you rejoin a room and don't receive updates, you get a partial view of the data
- if you have data connectivity issues, you get a partial view of the data
- you must have a WebRTC capable browser and Internet connection
Yeah I set out to build something with WebRTC rather than to build a planning poker app if that makes sense. Just wanted to test out the tech.
Having said that, I do still use this off and on and personally the limitations don't bug me too much. Would be a nightmare for more mission-critical software though
More, but I don't think it's a mind-blowing difference and I wasn't playing code golf when I wrote it. I wouldn't have used redux if I was!
https://github.com/ceuk/planning-poker