The client implementation needs to handle two scenarios that can cause race-conditions / lost messages:
nodejs-mobile has not started when the front-end starts, which means that messages sent via nodejs.channel will go nowhere and not receive a response.nodejs-mobile has already started when the front-end starts, e.g. if the front-end is slow to start, or if the front-end is reloaded (which does not reload the nodejs-mobile process). This is important because if we are listening for a "backend started" event to solve (1), then we would never receive that event in scenario (2).
I suggest wrapping this into the MessagePortLike abstraction, and queuing messages until we know nodejs-mobile has started and nodejs.channel is functioning. That way the rest of the app / api does not need to worry about this. This means listening for a "started" message that we will need to send from the backend when it first loads, to solve (1), and probably sending a "get state" message to the backend, and the backend to respond with the "started" message when it receives this message, to solve (2).
The client implementation needs to handle two scenarios that can cause race-conditions / lost messages:
nodejs-mobilehas not started when the front-end starts, which means that messages sent vianodejs.channelwill go nowhere and not receive a response.nodejs-mobilehas already started when the front-end starts, e.g. if the front-end is slow to start, or if the front-end is reloaded (which does not reload the nodejs-mobile process). This is important because if we are listening for a "backend started" event to solve (1), then we would never receive that event in scenario (2).I suggest wrapping this into the
MessagePortLikeabstraction, and queuing messages until we know nodejs-mobile has started andnodejs.channelis functioning. That way the rest of the app / api does not need to worry about this. This means listening for a "started" message that we will need to send from the backend when it first loads, to solve (1), and probably sending a "get state" message to the backend, and the backend to respond with the "started" message when it receives this message, to solve (2).