Sharing my thoughts on why using in-process/in-service websockets (socket.io style) is an anti-pattern and why some external middleware should be preferable. Having few microservices which are split among few processes (e.g. containers) means that various processes are holding sockets with clients, should one process is brought down (scale-out, in, upgrade version) we lose all its connections. Other than that, it becomes odd how various microservices are sharing the connections: per service TCP connection is too eager, sharing connection among microservices creates tight-coupling (e.g. the user service might get event of the order service). Sockets are just a stateful concept that we force into a stateless domain.The proposed solution: you wouldn't make your microservices API host a push notification service or SMS server, right? you treat those as external networking service. For that reason, it should be kept outside on a global stateful servers that do nothing but websockets communications. Every service that wishes to push to the client will call the websockets server.Firebase provide that functionality out of the box. Alternatively, you can host your own socket.io external service, on a separate serverWhat do you think?
Submitted February 18, 2018 at 10:56AM by yonatannn
No comments:
Post a Comment