Phoenix.Socket is one such abstraction. It doesn’t unify with regular HTTP requests (the Plug abstraction), but it is nice that it is not exclusively tied to a WebSocket-based implementation.

Phoenix ships with a LongPoll transport, and I can imagine one could write an alternative transport using POST+SSE, for example.

• Phoenix.Socket — Phoenix v1.8.8
• Phoenix.Socket.Transport — Phoenix v1.8.8

As @derek-zhou wrote, unifying HTTP and WS forces us to pick the minimum common denominator, and settle for the worse of both worlds.

• HTTP gives us caching, easier debugging, statelessness.
• WS is a persistent connection, less handshakes, harder debugging, stateful.

An abstraction over that would need to be stateless, not support caching/response headers/cookies, …

This difference between the two technologies is not only the cause of different pipelines in Phoenix (plugs vs on_mount), but also has a very deliberate use for certain scenarios that require one over the other, e.g. login/logout in LiveView requires a regular HTTP request to set cookies.

HTTP request/response and websocket streaming are very different things in both semantics and targeted applications; the former is more like UDP and the latter is more like TCP. I am afraid a grand unifying scheme will not exploit each to their full potential. An optimized architecture should be built from the ground up for either a connection or a connection-less networking API. I can cite 2 examples where crossing the 2 did not work out: HTTP/2 server push and Phoenix Socket over long poll.

Disclaimer: I hate React and I wish people would stop trying to force it into every shaped hole they can find.

I don’t think trying to create an abstraction over LiveView, HTMX, React, etc is a good idea. I was thinking more along the lines of the communication semantics.

If we could merge the apis for handling a route for HTTP request-response cycle and a stateful persistent connection (e.g. websockets) into a single uniform api, then the programmer wouldn’t have to choose a framework that’s good at realtime stuff to have stateful interactivity or a framework that’s optimized for incremental stateless updates for component-based DOM-patching, etc.

I’m not sure how feasible it is ofc since if it was a simple problem, it would have been solved a long time ago, but now that we have our choice of well-supported protocols for use in browser-based and service-oriented applications, it would be worth investigating a possible abstraction over all of them.

Not just a library that makes working with each different protocol easier we’ve got those already.

My initial thoughts were that separating out sending and receiving data into separate functions (either declarative or imperative doesn’t matter) would be a good first step.

For example, we can model a bi-directional websocket connection by implementing two handlers:

def push(%{updated: val} = state), do: {val, state}
def pull(%{updated: val} = msg, state), do: {:reply, Map.put(state, :updated, val)}
def pull(msg, state), do: {:noreply, state}

This same api would work for stateless HTTP request-response communication as well.

The implementation could raise or return a 404 or something else if returning {:noreply, state} from a pull/2 running over an HTTP1 connection.

I actually want this kind of api in a web framework regardless of its broader usefulness because I think it makes it complex connections more composable. In Python I use the Quart web framework for websocket stuff, and it has a single @websocket decorator for creating a websocket “route”, and the code inside that handler runs both sending and receiving messages, so I have to manually separate sending and receiving to make them run concurrently. Separating them out ends up making the code a lot simpler and easier to test as well though, so I think it’s a good pattern to enforce if possible.

P.S. I really think send/1 and recv/2 are better names for the above functions, but that would clash with Elixir’s process utilities, so