Clojurians Log v2

You’d have to trust the client to tell the truth about the state, which feels like a potential security issue, or you’d have to store the current state away somehow and recall it later. Or sleep the server, preserving in-memory content, rather than shutting it down. If you persist it, you’d have to get rid of it if the client goes away. Otherwise, a proxied WS feels like it should work. Ie., the proxy keeps the WS alive, and the connection proxy->server is what goes away. Electric’s liveness pings might not be compatible with this though, I’m not sure.

I’m going to predict that the Hyperfiddle team will say what they usually say regarding things like this: “It’s possible. It’s not a priority.”

ha ha yes

you can more or less model http transport as a really lagged websocket, so yes it can work in principle

the ws proxy is a neat idea

but you're going to hit a core impedance mismatch, software systems work best when the abstraction primitives align to the workload, and Electric is formally a signals/frp abstraction, which aligns to realtime stateful workloads. For example, Electric to this day is not great at transactional crud apps because the discrete transactional nature of the database needs to be unified with the continuous reactive nature of the views

We've got a clear hypothesis for transactions (informed by years of real world usage) with working POCs etc (see the e/Token primitive) but this didn't fall out of the computational structure for free like a lot of the query side primitives did

So, the closer you can unify with the signal workload shape, the happier you will be, and putting http RPC in the middle of a signal graph is the opposite of what you want