[Capricorn2481]

Looked into it more. A few questions I have

- Is this a lot of bandwidth when done over websockets? I was looking at the starter todo list on your github and everytime I type something a character into the todo list, I have what looks like 3kb of messages in the websocket passed.

- Is there anyway to get this working with multiple nodes? It seems like the way to use it is to bind it to a dynamic var that's only available in the library (`hyperfiddle.electric-dom2/node`)

[dustingetz]

you mean like multiple tiers, e/client e/server e/service1 e/service2? sure, we probably get to it next year unless a customer implementation needs it sooner

wire protocol is in verbose mode, we have a binary mode as well. it’s also not optimized at all because users already report tangible performance as “incredible” “unbelievable” as compared to the status quo graphql or http RPC or whatever. remember, http transport pays a TCP round trip just to syn/ack the connection before any app payload is sent! Electric wire traffic is also differential, i.e. collections are never sent twice only what changed.

[Capricorn2481]

Thanks for responding. You're operating at a high level and I'm an average coder, but I'm trying to understand

It sounds like you're saying Websockets have an advantage as an open connection. It's great that everything is differential, but I'm wondering what exactly is being sent when I type into a `dom/input`? If I write 1000 characters, that's 3mb downloaded. That seems like a lot for typing into an input. What is being diffed here if none of this state is going to anyone but me?

I'm sure it's early days in terms of documenting this for the layman, but I hope some day there's a guide that's easy to digest so I know how I could use it myself.

[dustingetz]

the DAG overhead is constant not linear, the overhead is mostly the protocol in verbose mode not binary (the difference is large), and as I said we have done no optimization at all (just naively sync entire DAG replicas on both peers requiring far more traffic than actually required) because tangible performance is excellent so far. 1080p youtube is 1MB/s for comparison and our phones have no problem with that. Framing performance as a compiler optimization problem opens the door to using all of compiler and graph theory to super-optimize this

[Capricorn2481]

I guess the question is should there be any overhead to typing into a text box? Even if that text box isn't sharing any state with the server? I understand you're solving a complicated issue, I'm just wondering what the design trade-offs were that led to that.

[dustingetz]

Ah ok the question is, what exactly is being streamed and why, given that the input state, per the todo-app AST, should not yet be transmitted?

The traffic here is "program debug state" — the electric callback was called on the client, so the client informs the server of this in case the callback has server regions. As you rightfully point out, there are in fact no server regions in that callback — and this is known at compile time — so there is no need to actually send that information, it is pure overhead.

The missing optimization is basically dead code elimination – we simply haven't gotten to it yet.

Note that the traffic is broadcast, not request/response, which means the user experiences no latency as the client is not awaiting any response from the server, it is simply keeping the server informed. Due to this, broadcasting "program debug state" like this is basically free, which is why we consider this optimization premature. We are much more interested in visible perf issues (how fast it "feels").

FWIW we are unhappy with dom/on (used in that tutorial) and it is about to be superseded, and the chattiness you observed is derived from one of the aspects of the design that we are fixing (there should not be a callback at all, the input should return its reactive state directly.) But to be clear the pattern is perfectly functional, it doesn't have bugs, and users are succeeding with it.

[Capricorn2481]

Awesome. Thanks for letting me know. Can't wait to watch your London Clojurians talk

[kaba0]

But websockets are quite expensive and requires huge server resources, aren’t they? Notably, lemmy instances can barely handle 1000s of people even when it is written in Rust because they (dumbly) decided to use websockets, when a forum absolutely doesn’t need it, and is more than fine with only approximately real-time data.

Don’t get me wrong, I don’t claim anything general with this, of course WebSockets have their uses and I’m sure Electric Clojure uses them more responsibly, it really is more of a question on what do you think of it. Elixir also has WebSocket solutions, so it seems to be a more common solution nowadays.

[dustingetz]

LiveView at 2 million clients on 40core/128gb box, limited by ulimit: https://www.phoenixframework.org/blog/the-road-to-2-million-...

discord uses websockets, here are some more links: https://www.reddit.com/r/elixir/comments/pophiz/server_specs...

we'll have seamless reconnect soon, which means the ws connections can actually drop when inactive (no heartbeats!) and then reconnect when the client wants something, so the forum use case should be quite fine. Not everything needs to be realtime server push, so refactor your code so that queries run on page nav or something. Electric is network transparent but that doesn't mean the network is opaque, the reactivity graph is in userland control (as declared by your AST) and the network data flow is implied by that same AST, same reactivity graph!

[kaba0]

It makes sense for a real time chat program, especially with voice chat. Not really for a mostly-static, reddit-like client.