- Bring up the development env for demo:
- To tear down any previous runs:
docker-compose -f docker-compose.local.yml down
- To run:
docker-compose -f docker-compose.local.yml up --build
- No need for authentication in the
notifier
service as thesocketId
assigned to each webapp is just as random as any password and short lived (user may close the browser/tab when finished).
- The current
notifier
service does not scale well.- If we scaled up as-is then each instance will manage its own websocket connections
- For example,
docker-compose scale notifier=2
:notifier_1
will managesocketIds=[x,y,z]
notifier_2
will managesocketIds=[a,b,c]
- a worker request to notify
socketId=a
might get routed tonotifier_1
and that wouldn't be very helpful- if the
notifier
service was updated to be backed by a pub/sub queue so that workers could publish notifications to the queue directly and all the notifier instances could subscribe to the queue then notifier service would scale better.
- if the
- If
socketId
changes because the webapp is refreshed or the user restarts browser/tab:- Any background tasks that were kicked off before such an action will not be able to send notification. Because the previous websocket connection (referenced by the outdated socketId) will no longer be active.
- To workaround this, we would need to ask
notifier
to work with username instead ofsocketId
for notifications. Here's a diagram that zooms in on proposed changes. It does not show that the payload traveling betweenwebapp > webserver > queue > worker > notifier
will now containusername
instead ofsocketId
... but hopefully that is obvious.
- socket-redis may be a great out-of-the-box scalable alternative to run as the
notifier
service