Considering one scenario, one user open the webpage, and the front-end call GET /pixels to initialize the board state. Before front-end finishes initializing board state and establishing socketio tunnel with server, the server receives an update from one pixel generator. In this case, this update after the front-end GET /pixels and before it connect to socketio to listen socketio event will never get reflected in the webpage!
There are several ways to fix it. We could first look into the socketio protocols, if the socketio natively solve the concurrency problem by making sure all event sent will be received in order, then we could just provide another socketio event "init" so that the front-end could just listen "init" event and then "pixel update" event. Otherwise, we should introduce some version control mechanism to resolve the concurrency problem.
Considering one scenario, one user open the webpage, and the front-end call GET /pixels to initialize the board state. Before front-end finishes initializing board state and establishing socketio tunnel with server, the server receives an update from one pixel generator. In this case, this update after the front-end GET /pixels and before it connect to socketio to listen socketio event will never get reflected in the webpage!
There are several ways to fix it. We could first look into the socketio protocols, if the socketio natively solve the concurrency problem by making sure all event sent will be received in order, then we could just provide another socketio event "init" so that the front-end could just listen "init" event and then "pixel update" event. Otherwise, we should introduce some version control mechanism to resolve the concurrency problem.