Hacker News Reader

Comment by chrismccord | Hacker News Reader

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.

View on HN

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.

> 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.

We are happy users of libcluster but there's also https://github.com/mrluc/peerage for automatic node discovery.

Yes, connecting to any node connects you to all nodes. I have done exactly this in a production app.

Hey Chris! first of all thanks for your work on Phoenix and the excellent book about it. Phoenix solves many of the problems that held me away from Rails, much as I wanted to get good at it because I really liked Ruby.

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.

> 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)?

I'm obviously not Chris, but this is something that's been discussed in the community and the way it's ended up is that you have an Elixir application, not a Phoenix application.

The way to treat it correctly in most cases is to have a Phoenix app be a part of an umbrella project where Phoenix handles the web component and very likely you'd have things like data and other services in one or more other applications inside the umbrella project.

If you're curious about Elixir and Phoenix I highly recommend http://elixirforum.com/ where you can find a great community for asking questions and learning more. Things like these come up every now and then and you get to be a part of the conversation and take everything in from both core members of the major projects to just other regular users.

Thing is, if the right way to do it is an umbrella project, why does Phoenix 'take charge' by default (mix phx.new)? There's other similar stuff I ran into that I can't think of right now, but it's an example of what causes this confusion.

I mean, I understand if the explicit goal of Phoenix is the provide an easy entry point for Rails devs, but I guess I'd like it if that was more explicit.

All that said, I'm being nitpicky/pedantic. I love both Phoenix and Elixir, and the ecosystem. And yes, I've been enjoying the elixir forums. Do you happen to know if there's some way to get a decent mobile version?

What do you mean by `mix phx.new` taking charge?

    $ mix new elixir_umbrella --umbrella
    $ cd elixir_umbrella/apps
    $ mix phx.new elixir_umbrella_web

This should work just fine and it means that this phoenix application is a sub-application in your umbrella project. Likely you'd do a `mix new elixir_umbrella_cool_service` to handle DB and service stuff that is more about business logic.

I can sort of see what you mean by Phoenix doing magic, because a lot of what you see on the surface looks like magic, but it's hard to really discuss these things when one can't pinpoint what the actual issue is.

On the idea of rails developers having an easy time, I don't really think it's that big a part of the concept, to be honest. A rails dev expecting rails is going to drown in BEAM/OTP things anyway provided he isn't making the same postgres + web-server applications without any real value from the BEAM, so I don't think the idea is to really cater to that kind of thing anyway. I'm not a rails dev, so I can't really say what their feeling is.

Thanks a lot for Phoenix and for taking the time to write such an informative comment. I really admire your open-source work.

Reply on news.ycombinator.com