What’s the big idea? After scrolling and clicking I’m not sure what this gets me. What’s the durability guarantee? Is this at-least-once, at-most-once, or thoughts-and-prayers message delivery? What happens when a node crashes?
elixir has an even better offering baked into phoenix. unlike node which is limited to 1 process and necessitating a complex IPC cluster, erlang's vm can use all cpus on the host as well as connect different machines. The end result is a much more robust websocket solution that can relay state to whichever machine resumes the connection.
> Are you talking about channels or some other concept?
yes channels. I used them to power the websockets system for my startup. workes 100% as advertised out of the box with no special configuration. Handles thousands of messages per hour at the moment.
architecture docs are scant, but it appears this horizontally scales channels by adding "broker" instances and horizontally scales consumers by adding "worker" instances? i.e. a broker only needs to ever broadcast a message to the maximum number of worker instances in the cluster.
SocketCluster's approach to horizontal scaling with pub/sub channels and rooms is elegant. The support for both HTTP and WebSockets through the same port simplifies deployment, and the circuit breaker pattern is a smart choice for resilience. Impressive that it's maintained for 10+ years.
SocketCluster's approach to real-time communication with pub/sub, horizontal scaling and automatic recovery seems solid. Their focus on simplicity while handling complex distributed systems is impressive. I wonder how their performance compares to Socket.IO or Centrifugo in high-load production environments.
What’s the big idea? After scrolling and clicking I’m not sure what this gets me. What’s the durability guarantee? Is this at-least-once, at-most-once, or thoughts-and-prayers message delivery? What happens when a node crashes?
elixir has an even better offering baked into phoenix. unlike node which is limited to 1 process and necessitating a complex IPC cluster, erlang's vm can use all cpus on the host as well as connect different machines. The end result is a much more robust websocket solution that can relay state to whichever machine resumes the connection.
Are you talking about channels or some other concept? https://hexdocs.pm/phoenix/channels.html
> Are you talking about channels or some other concept?
yes channels. I used them to power the websockets system for my startup. workes 100% as advertised out of the box with no special configuration. Handles thousands of messages per hour at the moment.
architecture docs are scant, but it appears this horizontally scales channels by adding "broker" instances and horizontally scales consumers by adding "worker" instances? i.e. a broker only needs to ever broadcast a message to the maximum number of worker instances in the cluster.
SocketCluster's approach to horizontal scaling with pub/sub channels and rooms is elegant. The support for both HTTP and WebSockets through the same port simplifies deployment, and the circuit breaker pattern is a smart choice for resilience. Impressive that it's maintained for 10+ years.
SocketCluster's approach to real-time communication with pub/sub, horizontal scaling and automatic recovery seems solid. Their focus on simplicity while handling complex distributed systems is impressive. I wonder how their performance compares to Socket.IO or Centrifugo in high-load production environments.