[andrewstuart2]

SSE is awesome, and Gin seems to have a nice implementation. I definitely like the usage for realtime streaming stats since that's a one-way stream.

Chat, however, would be better served with websockets. If it's bidirectional, use websockets and avoid both upstream and downstream cost of setting up a connection.

SSE works, but you should consider it tech debt if you decide to go that way.

</psa>

[jkarneges]

WebSockets will definitely provide the lowest latency for client->server transmission, but calling SSE "technical debt" for a chat service is a bit harsh. Many chat services get by just fine with HTTP POST for message submission. It's a case of trading low latency for simpler tooling.

Here's a recent article about Secret using POST for sending: https://medium.com/@davidbyttow/scaling-secret-real-time-cha...

[andrewstuart2]

It's not so much latency to me. It's the waste. There's both extra latency and extra byte overhead. It's a trivial implementation difference (in all the frameworks I'm familiar with) and as developers, I think we have a responsibility to be efficient and not waste energy and bandwidth.

At scale, you might be talking hundreds or even thousands more clients per server (depending on the server size). On mobile, you use less data which fires up the radio less which directly translates to battery life.

Assuming that your application gets any sort of traction, the 30 minutes of dev time you saved may have a much higher net impact on the world purely by the multiplicative effect. When your product affects that many people, you should remember that you have a responsibility to be sustainable.