I'm looking for a solution for this, buffering messages in an array and send them after web-socket reconnect. I can check the socket client and push messages to an array when connection is lost and send them after reconnect, But how i can find which message was sent to show a check icon on client side? A solution seems to be sending a uuid from client side as message client side identifier and check it after receiving acknowledge from the server. But any better solution or articles about this?
This is a standard problem that messaging middleware / message brokers solve.
I believe your question hints at using a UUID as a message-id, but I will flush out the details, to help you cover all the bases:
Typically message brokers use distinct "messages" each of which have a unique message-id, the sending system buffers up all messages and only removes the message from the buffer once it has been acknowledged by the receiving system.
If a disconnect occurs, the sender resends all unacknowledged messages. The receiver must acknowledge all such messages (even if they are duplicates - so that the sender can remove the messages from it's buffer) and then proceed to either de-dup the messages or (ideally) if the messages are idempotent they can be processed again.
I believe that you can directly connect to some message brokers using a websocket via protocols such as STOMP, so that might be an option for you. However it's likely that you are not the first person to come across this problem regardless of what tech stack you are using, so I would look for a library/framework that handles the low level messaging for you.
But how i can find which message was sent to show a check icon on client side?
I am not sure what you are asking here. If you are expecting a message from the client and don't receive it, you might be able to detect that with a timeout.
Additionally you can check the websocket (link) status via some kind of heart-beat. As long as your application is constantly generating new messages, you can check to see how long its been since you last received an acknowledgement, once a timeout/threshold is reached you can then take action (reconnect/notify/etc).