Consider ServerSentEvents over WebSockets?

[jwoertink]

I just saw this article https://germano.dev/sse-websockets/ I need to read it a bit more and really understand it, but overall the concept seems fairly straight forward. It made me think.... what if Lucky just implemented SSE out of the box instead of the traditional websocket handler option like I was attempting in https://github.com/luckyframework/lucky/pull/1305 :thinking:

So far using https://github.com/cable-cr/cable with Lucky has been awesome for websocket usage. I haven't worked on that other PR because there really isn't much of a need, and it's a pretty complex area. But if we could get something built-in that's a lot easier to understand and use, maybe it's a better alternative?

[robcole]

I was just reading the same article, and I love the idea, at least in abstract.

We can also make inroads to making ActionCable work out of the box later, but SSE seems like it could be pretty sweet as a default.

It’s also worth noting that until we have HTTP2, the gains from SSE will be capped:

Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, which means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com (per Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100).

[robacarp]

Server sent events are great. The http/2 problem is fine, and that just means when we do get http/2 from crystal core it'll be easy to get the best from sse too. 🥳

[rmarronnier]

FWIW, here is a long and dense reply to the initial article : https://www.mnot.net/blog/2022/02/20/websockets