Open devensiv opened 2 years ago
There is one more solution:
Instead of having a seperate event for each chat room.
We can just have one on_message
event which contains both the message and a room id.
And honestly I highly doubt a single event channel will ever be bottlenecked by messages.
How about we scrap all the previous ideas and just open the frontend room UI and subscribe to the message event before the room has been established: From the requesting client side: we would open the room UI at request time (and simply close it or hide it again when the request was rejected) From the receiving client side: we open the room UI as soon as we get the request and close if needed (when we reject the attempt)
There is a race condition while opening a room. There might be messages received from the peer before the front-end starts "listening" for the the message_received event causing the message to never arrive in the front-end
I have 2 possible solutions for that in mind:
1. Ping-Pong-Peng
front-end implementation of something similar to the P3 maneuver that we use in hole-punching -> this requires 2-3 messages to be sent by both either side of the conversation (best case 4 messages in total, worst case 5 messages in total)
2. more events
front-end sends an event to the back-end to let it know that it can now emit messages_received events -> to do this properly this requires caching messages in the back-end
3. Dirty Solution
The dirty solution would be to add a delay before we start to send messages after opening a room. -> for sensible delays this just makes the occurrence less likely and does not solve the core problem -> this is the least work