-
Notifications
You must be signed in to change notification settings - Fork 2
Realtime Push Notification Strategy
in order to update different parts of the app on any new events affected by db updates I've used actor design patterns and TCP based pubsub pattern like so:
this actor will be called whenever a new event data want to be broadcasted to other parts of the app, in these situations we'll publish new event data to a redis pubsub channel constantly until a subscriber receives it. I'm using actix-redis crate to do so.
this actor must be started in a place where the HTTP server is being started and passed as a safe shared data to the HTTP app_data() method so we can extract it and send message to it to receive new event data as a notification. basically inside the started() method of this acotr an interval will be executed in which an async method is being executed periodically inside a tokio::spawn() threadpool, the codes inside that async method must be the logic of constant subscribing to redis pubsub channel related to new event data using while let Some(...) syntax, once we receive the data we can update db records and the state of the actor itself or notify other actors with newly event data using actix-broker crate which allows actors to talk to each other using a topic based local pubsub pattern.
there must be either a websocket route or HTTP api which can be called to send message to the subscriber actor to receive new event data related to the passed in client id (user_id), in the case of HTTP api, the api must be invoked periodically from the client to receive new event data constantly but since websockets are full-duplex connections there is no need to invoke the route as long as the connection is open. I've used an HTTP api to receive notifications since it uses less traffics and server loads!
note that in the case of websocket logic server actor must send the received new event data to the related ws session actor.