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.
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.
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
So you mean, that in raxx we would open a Server Stream for each user and then when someone sends a message to a user use that specific stream? I think I’m just missing some basic understanding of how SSE work. What happens when the users are not online? Is the SSE stream closed or due to the way they are implemented it doesn’t matter?
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.
That’s what I’m doing here but you could also stream content on a single request from client to server.
However there is no need to do that. A new POST request to the same endpoint with same headers reuse the header information from the connection HPACK state so have minimal overhead.
No. All requests multiplexed through a single connection. That’s the main purpose of HTTP/2. A request or response streaming content still uses just one stream.
Gotcha, so to make sure I’m understanding, the html page is sent, then this connection is closed. The EventSource request is made, then subsequent POSTs are shared under the single connection, or is the original html request kept alive for a certain amount of time and both SSE and POSTS share the same original connection?
How would this work without a JS interface for bidirectional http2 requests? I was really hopeful about H2 wrt to browsers and obviating websockets, but I don’t see a clear path there without a way to write a real http2 client on the browser? For example, Gary on the Phoenix team wrote an H2 channels transport and it works from a non-browser http2 client, but there’s no path to get it in place in the browser. Am I missing a step in the h2 story on the browser today?
The goal would be how do we create a bidirectional http2 client in the browser that allows us to have a stateful handler on the server, just like a websocket handler? If the only way to achieve it is to simulate with POST’s and SSE’s, then we’ll need to wire up the http requests back to the SSE stateful handler which is a lot more work than the bidirectional pipe and browser API that websockets gives us.
Sure. My point was that with this combination, bidirectional communication is possible. Both the client and server can manage state so anything that is possible with websockets is also possible without. The architecture of the sever could certainly make implementing this easier or harder to do.
Personally, if I cared about some stateful communication I would move that state out of any request processes which would then interact with both SSE and POST/PUT handlers. Then you can use Last-Event-Id to re-establish a connection. or not depending on choice of at-least-once vs at-most-once.
If that’s the goal then any other option will look like more work than just using the websocket handler.
