3 ms·
Absolutely right, until you have multiple instances of backends you need to deal with and synchronize, which is a pain in the behind. The OPs main issue seems t
by superice 5y ago
Absolutely right, until you have multiple instances of backends you need to deal with and synchronize, which is a pain in the behind. The OPs main issue seems to be with that problem, which is the tough component of using something stateful like websockets anyways. The impedance mismatch of ‘something happened in the database’ to ‘send event over websocket’ is painful in a multi backend instance environment.
Case in point: dossier locking in the product we both worked on. Hi Jeroen! Always nice to find an old colleague on here :)
- jeroenhd 5y agoHa, hey there! Nice username :) You're totally right, of course; for shared states between different backend instances you'll need a different solution, like database locking or complicated inter-backend API calls, or even a separate (set of) microservice(s) to deal purely with websockets while other backend operate on the database. That way you can apply scaling without data consistency issues, if you want to go for a really (unnecessarily) complicated solution. It all depends on your problem space. If you want to make a little icon go green on a forum because someone commented on your post, I think websockets are perfect, much better than the long-lived HTTP polls of yore. I think the OP is using websockets to synchronize game state across different clients, which can be quite tricky even without having to deal with scaling or asynchronous connections. You can use websockets for that, but manual HTTP syncs/websocket reconnects after a period of radio silence would not go amiss. Hell, if it's real-time games this is about, you might even want a custom protocol on top of WebRTC to get complete control over data ad state with much better performance.