Watercooler; A chat app with no websockets needed

But how would one handle messages just between two (or more, but not all) users?

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.

HTTP2 browsers multiplex all requests over a single connection by default I think, but I’m not able to find a reference that says that is required.

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?

There are two things that come to mind with regards to SSE that are worth mentioning:

1. No support in IE or Microsoft Edge (yeah, I’m serious!)
2. Text only - no support for binary data.

No. the html page would just be an earlier stream in the same connection.

I’m not sure what you mean here. What’s the goal?

True but there are polyfills. So a channels.js thing could be made if it included that polyfill

Not looked into this so far but I think you can use the same browser api’s that make the polyfil work to implement this