This is an epic issue that will resolve the problem of notifications in the chat system.
Here, we leverage the real-time functionality of the web-socket to enhance the UX.
To clarify, consider these scenarios:
When a user is online and there are some messages directed to this user, we will first use client-side rendering to prevent the delay from the database queries, i.e., client-side will have a data structure [a map? with roomId as key] to keep track of the newly-added notifications and display via (1) at the end of the chat room name, for instance. This will provide a quick response to the display and UX.
Importantly, front-end must also detect if the message is directed to the room in which the user is currently watching or not. In this case, the front-end must also call an API to tell the database that this message have already been noticed. Think of the LINE application, when we are actively chatting with someone, the application simply just displays the message and NO notification has been created. Front-end could call this API asynchronously to avoid blocking.
Next up, when user switches room, front-end must remove the (1) notation from the client-side rendering mechanism to tell the user that they have already viewed the corresponding notification. Front-end also needs to call API, provided by the back-end, to tell the database that the corresponding notification has been viewed/noticed.
Finally, when user disconnects from the session and reconnects back in, front-end must query the persisted, unnoticed notification from the database, for data consistency, and continue with the display. The delay in this phase is ACCEPTABLE as it occurs only once -- only when the user connects back in. LINE application also has this delay.
To summarise, the back-end will provide 2 APIs:
Clear Some Notification
Retrieve All Remaining Notification
If you have any discussion about this implementation, please do not hesitate to let me know.
This is an epic issue that will resolve the problem of notifications in the
chatsystem.Here, we leverage the real-time functionality of the web-socket to enhance the UX.
To clarify, consider these scenarios:
When a user is
onlineand there are some messages directed to this user, we will first use client-side rendering to prevent the delay from the database queries, i.e., client-side will have a data structure [a map? withroomIdas key] to keep track of thenewly-addednotifications and display via(1)at the end of thechat roomname, for instance. This will provide a quick response to the display and UX.Importantly,
front-endmust also detect if the message is directed to theroomin which the user is currently watching or not. In this case, the front-end must also call an API to tell the database that this message have already been noticed. Think of theLINEapplication, when we are actively chatting with someone, the application simply just displays the message andNOnotification has been created. Front-end could call this API asynchronously to avoid blocking.Next up, when user
switches room,front-endmust remove the(1)notation from theclient-siderendering mechanism to tell the user that they have already viewed the corresponding notification.Front-endalso needs to call API, provided by theback-end, to tell the database that the corresponding notification has been viewed/noticed.Finally, when user
disconnectsfrom the session andreconnectsback in,front-endmust query the persisted, unnoticed notification from the database, for data consistency, and continue with the display. The delay in this phase isACCEPTABLEas it occurs only once -- only when the user connects back in.LINEapplication also has this delay.To summarise, the
back-endwill provide 2 APIs:If you have any discussion about this implementation, please do not hesitate to let me know.