Usual ways to keep client in sync with server are;
Polling via REST: Basic call made every X duration but is inefficient if calls are made very frequently.
Polling via Socket: Establish a single socket connection and listen to channels. Best to use if sync has to be made almost realtime but socket's lifecycle has to be maintained properly to avoid leaks.
So w.r.t building notification system, I'll write down how I do it, might be of help for you:
Establish socket on application load if user has already authenticated otherwise establish conn. after Login/Signup success
Listen to some X channel on the established socket to keep Notification unread-bell number(like in Hashnode) in sync, so that as soon as new notification arises in the database, the server will push the new unread count on the socket to the same X channel.
On click of Notification bell, you make server call to get top X notifications along with read/unread status.
(optional) Another version of Point 3; Persist unread count and first response of Get Notifications API call in the memory. After that, make server call only if unread count is more than zero otherwise show the previously persisted notifications so that you'll save unnecessary network call.
Great !! Alright I got your points . Okay so about the creating the socket connection when user is auth. In this i am using jwt so how the things gonna be! Like if there is a jwt in cookie or localstrage then create the socket conns . Like a middleware ! Right?
@Aniketh: Middleware is not necessary for establishing connection. Usually, establish socket connection at the start point of your server call and in the middleware, you manage the socket's other lifecycle stages.
Also, I'm answering with several assumptions in your approach. There could be other efficient approaches too