I’m creating an app where I want to push (game score) updates to my clients, with clients participating in different games. There is no need for bidirectional traffic, the clients will only rarely push updates and the updates do not need to be real time so they can HTTP POST just fine. Updates will be irregular, only several times per hour, and it won’t really matter if there’s a delay in them.
I’ve been looking, naturally, at Phoenix Channels to achieve this outcome. WebSockets seem like an obvious way to go here, but since I don’t need the bidirectional traffic that they offer I’m wondering if there is an alternative solution and if there is a benefit in NOT using websockets.
I think server-sent events (SSE) is a perfect fit for my use case, but since Phoenix Channels don’t support them out of the box, I would have to build it myself as an alternative transport mechanism, which doesn’t seem trivial when looking at the current longpoll implementation. Which seems like development overkill, with easy WebSockets beckoning enticingly. I’ve come accross this project, but it doesn’t tie into channels as far as I can see, only allowing pushing to all clients, which is not what I’m looking for.
And then there is long polling, which I don’t really want to do because polling.
Is this really a sensible thing to worry about? Will (for example) the memory footprint of WebSockets actually exceed SSE’s, which will also need to be tied to their own process-per-client? If using SSE or long polling will allow me to serve twice (or more) the amount of concurrent users, than perhaps its worth doing, otherwise maybe I should just use sockets. Any thoughts? Experience with SSE?