Live data from Hacker News

Phoenix WebSockets under a Microscope

zorbash.com

1–10 of 25 posts

Re: Phoenix WebSockets under a Microscope

#4
post #3

Just to highlight - this is in no way related to the existing Apache Phoenix project, or to the ten other tech projects also called Phoenix. ( https://en.wikipedia.org/wiki/Phoenix#Computing ) This is a new one.

Well, relatively new. It was actually the one I was expecting when I clicked through (the Erlang/Elixir web framework). Give it had websockets in the title, I would have been surprised if it wasn't.

I'm surprised that any hacker news reader would actually think anything else, given how often this particular Phoenix has surfaced here.

Re: Phoenix WebSockets under a Microscope

#5
post #3

Just to highlight - this is in no way related to the existing Apache Phoenix project, or to the ten other tech projects also called Phoenix. ( https://en.wikipedia.org/wiki/Phoenix#Computing ) This is a new one.

Very much not new, but newer... sure

Re: Phoenix WebSockets under a Microscope

#6
Phoenix creator here. Happy to answer any questions. This article does an excellent job diving into the underlying details of Phoenix channels and pubsub.

For those that want a thousand foot view and are curious what makes Elixir and Phoenix unique compared to other solutions, think of Phoenix channels as trivial realtime communication that is distributed out of the box. With Elixir, processes (green threads) are load balanced on both IO and CPU so no single channel client will block another, regardless of the work you may be doing. Channels are also multiplexed on a single concrete connection so the same client can be doing intensive work in one channel while receiving messages over another. The runtime is also distributed, so process messages can reach any server in the cluster which is what allows you to `broadcast(socket, "event", msg)` in a channel and it Just Works across the cluster.

Re: Phoenix WebSockets under a Microscope

#7
One of the highlights for Phoenix WebSockets came from the insights of one of my co-workers. I was having a problem where I only wanted to send websocket traffic up to 1 time every 3s (debounced essentially). I was struggling with this solution and came up with a hacky solution that would debounce on the event broadcast side (vs the socket side). This means it would be up to 1 time every N seconds per server.

Co-worker showed me that sockets are just processes, and that once the process exists, I can treat it like any other process. We wrote a fairly simple state machine for debouncing, and made it debounced on the socket side. It's awesome because it's debounced even in a distributed setup. Less than 25 lines of code for all of that!

Re: Phoenix WebSockets under a Microscope

#8

Phoenix creator here. Happy to answer any questions. This article does an excellent job diving into the underlying details of Phoenix channels and pubsub. For those that want a thousand foot view and are curious what makes Elixir and Phoenix unique compared to other solutions, think of Phoenix channels as trivial realtime communication that is distributed out of the box. With Elixir, processes (green threads) are loa…

Thanks a ton for Phoenix :D Re the clustering support, I can see in your article here https://dockyard.com/blog/2016/01/28/running-elixir-and-phoe... that the Erlang VM joins clusters on startup - any idea if it's easy or possible to dynamically join and leave clusters?

Sort of what you'd expect in a cloud environment: one or two bastion servers would have a known IP address, and the remaining would be expected to learn about the cluster when the joined with the bastions.

Re: Phoenix WebSockets under a Microscope

#9
post #8

Phoenix creator here. Happy to answer any questions. This article does an excellent job diving into the underlying details of Phoenix channels and pubsub. For those that want a thousand foot view and are curious what makes Elixir and Phoenix unique compared to other solutions, think of Phoenix channels as trivial realtime communication that is distributed out of the box. With Elixir, processes (green threads) are loa…

Thanks a ton for Phoenix :D Re the clustering support, I can see in your article here https://dockyard.com/blog/2016/01/28/running-elixir-and-phoe... that the Erlang VM joins clusters on startup - any idea if it's easy or possible to dynamically join and leave clusters? Sort of what you'd expect in a cloud environment: one or two bastion servers would have a known IP address, and the remaining would be expected to le…

> any idea if it's easy or possible to dynamically join and leave clusters?

Don't know the specifics in Erlang, but in Elixir you can just use Node.connect/1 and Node.set_cookie/2: https://hexdocs.pm/elixir/Node.html

Edit: There's also stuff like libcluster (https://github.com/bitwalker/libcluster) that allow for this at a higher level afaik.

Post reply on HN