I built a small notification api system that has id, user_id, subject, text, status, created_at columns in the data base.
My current process is that when a user requests for her notifications i get the most recent 100 unread messages and send to the user, then wait for the front end to send me a list of ids of those that have been read by the user so that i can change their status to read.
but sometimes this does not happen meaning the when the user requests for another set of messages they will get back their already read messages.
So i am thinking of marking the messages as read once i retrieve them for the user rather than wait for update from the frontend.
but i am not sure if this is the best way to handle this! is there a better process for api notification systems please advice me. Thanks.
I would think about it like this: What is that listing of unread items depicting? What the state understands to have been left unread. Is pulling a listing of unread items really meant to denote all those items were read? I think not. You may allow a bulk mark read, but reading the list is just a stateful representation, of fact. Read the list, and authoritatively mark read when touched by a visible interface component by sending a per-item request to thing/mark-read.
If you're having issues with the (central) store not representing state accurately because you think they should be read, debug your interface. I would not mark read on pulling the list, though. That would be a flawed approach.
If you do directly insert all 100 into the display where you consider them read, create an endpoint in your api for thing/mark-items-read and pass it those 100 item ID's.