At the same time, if channels fit what you want to do, they're awesome. Adding collaborative editing is super easy.
Phoenix WebSockets under a Microscope
11–20 of 25 posts
Re: Phoenix WebSockets under a Microscope
#12Phoenix 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…
Re: Phoenix WebSockets under a Microscope
#13Earlier quoted context omitted.
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.
Re: Phoenix WebSockets under a Microscope
#14One 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-work…
Re: Phoenix WebSockets under a Microscope
#15One 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-work…
Re: Phoenix WebSockets under a Microscope
#16One 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-work…
Re: Phoenix WebSockets under a Microscope
#17Phoenix 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…
Re: Phoenix WebSockets under a Microscope
#18Phoenix 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…
Secondly, thanks for your role and Jose's in the community. While I think the language and framework are most important, I feel that a certain 'culture' that pulled me into Ruby/Rails is also present in the Elixir/Phoenix community.
One question I have, and I apologize if I'm not doing a good job putting it into words, is: how you see Phoenix within the larger ecosystem of Elixir/Erlang/OTP?
I found that reading the 'Programming Elixir' sometimes clashed somehow with the 'Programming Phoenix' book. The former spent quite a bit of time explaining and getting me excited about OTP and idiomatic Elixir and all, while the latter felt a bit like spending time comforting me that all this was just like Rails, but better, then pulling the rug from under me by introducing channels, and ultimately leaving me feeling like somehow Phoenix, or at least how it was presented in the book, isn't entirely in line with the Elixir/Erlang/OTP approach.
That might sound 'snarkier' than it's meant, but I mean it as a question from someone who hasn't gotten this excited about a programming language/ecosystem in a long while.
It's more from a sense of confusion: Should I go for an umbrella app where Phoenix is just one app that communicates with others? Or something that is primarily a Phoenix app (as the book suggests, IIRC)? Despite the relative lack of magic, isn't Phoenix still a bit too magic by hiding the OTP stuff (or at least that's the impression I got from the Phoenix book)?
I have to admit the learning process has become a bit of a blur, this many months in, so I might be entirely wrong about the particular. Mostly I just felt a kind of schizophrenia as I was learning Elixir and Phoenix, and unless that is entirely baseless, I'd love to hear your thoughts on the matter.
Re: Phoenix WebSockets under a Microscope
#19One 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-work…
I'd love to see a blog post on this. Sounds like a good candidate for the Elixir Radar.
Re: Phoenix WebSockets under a Microscope
#20One 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-work…
I'd love to see how you accomplished this if you wouldn't mind sharing a gist or a post?
This would be an interesting blog post, as the format for the state machine and logic behind it are quite fun.