I want to build a similar notification mechanism that Facebook handles.I actually store the user's notification in an SQL table (actually it's a graph database but everybody master RDBMS terms). I'm interested in the case where the user clicks on the icon:The counter should get a value of 0 internally and visually disappears.How the clearing of this counter should be made? On clicking, call a Rest API that flags each notification as being read (table's column READ)?Drawback would be that it would take some time if there was huge amount of notifications to flag in order to get the counter to 0 and making it disappear.Having a kind of column for each user called HAS_NEW_NOTIFICATION that is valued as false each time the icon is clicked (through a REST API call), if the counter was present.Thus, the counter would be present only if the flag value is true.What would be a good practice?
Good way to handle the notification counter like Facebook does
web development;architecture;database;rest;facebook
The best practice is to store a datetime stamp in the user's table that indicates the last pull by the browser for notifications. Any notifications created after this datetime stamp would be counted as new and unread.The database can index notifications by their created datetime stamp efficiently, and adding a flag if read shouldn't impact performance. Since you are always searching for notifications after a give datetime the performance should be okay.You just need to update the user's table of what the oldest unread datetime stamp is. That gives you a place to query the notifications for new and unread items.If there are no unread items then the user's timestamp is updated to the last time the browser pulled for a check.