Crowdhailer
Watercooler; A chat app with no websockets needed
Project link on github: GitHub - CrowdHailer/watercooler: Building a distributed chatroom with Raxx.Kit · GitHub
No Websockets?
When viewing this application over https content will be served over a single connection using the HTTP/2 protocol. One of the streams is used to stream server sent events from server to client. At this point both client and server can freely send messages to the other. Bidirectionally communication is achieved using a single TCP connection.
There is a very nice JavaScript API to react to server sent events in the browser. The API in the browser is EventSource (slightly confusing but it has nothing to do with EventSourcing the architecture).
The need for bidirectional communication was the motivation for websockets in HTTP/1.
However because a stream of server sent events can share a connection with other requests from client to server there are very few reasons to keep using websockets with HTTP/2.
Most Liked
michalmuskala
Do you think it would be possible to provide a transport for phoenix channels working over SSE? Or something similar. I know there were some issues with that at one point, maybe it’s possible now.
Crowdhailer
I can’t think of any reason why it wouldn’t be possible.
Any form of identification for a user would work. you could use their ID as a key for the SSE request process in a process registry.
This example is just meant to be the simplest possible case of sending events to a client and I didn’t want to confuse that with authentication concerns
chrismccord
This is neat! Can you clarify EventSource and bidirectional events? As far as I’ve found, there’s no JS api for bidirectional events over H2, so sending events to the sever must happen over a traditional POST request, which I thought would be a new connection? I didn’t know EventSource on H2 would grab the existing connection, so if thats’ the case that’s awesome. I would really love for a bidirectional API to be standardized on the browser so we could get stateful websocket-like handlers on the server side, but I haven’t seen any movement in this area.







