Hacker News new | comments | show | ask | jobs | submit login

Phoenix creator here. I would be happy to answer any questions. For those that want an overview of the framework, my ElixirConf talk would be a good start: http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-...

Can you give a briefish but honest assessment about how Phoenix outdoes going with your stock Rails stack, and how it might make a few things harder? How would I differentiate/"sell" an Elixir/Phoenix stack (say, for an API) to a manager? How does Phoenix differentiate itself from Rails, and how difficult is it to switch, and under what circumstances?

(I say this as a fan, btw! I just think that it's important to get the pros and cons out there. I also think that a lot of Ruby/Rails folks are VERY curious about Elixir generally and Phoenix specifically, lately...)

Sure. So let me start by saying I have worked full-time in Ruby/Rails at a Rails shop for the last four years. Phoenix is derived from that experience, and we borrow some great ideas from Rails.

Pro - Concurrency: I really love Ruby/Rails, but what led me to Elixir in the first place was constantly dealing with lack of concurrency in Rails and being unable to do anything like websockets in a sane way. For example, in Rails we can't really block in the controller without killing throughput, so we go to great lengths to background everything. This makes simple problems like "Make a remote API request through a controller" way harder since we now have to throw it in a worker queue, then poll from the client on the status of the job, then finally return the result. In Elixir/Phoenix, we can block in controllers without a blip on throughput, do our work, and return the response.

Pro - Error Handling / Fault tolerance I won't go into too much details here, but the Erlang/OTP way of building applications around Supervisors and responding to failures has really blown me away. Erlangers have been sitting on this innovation for the last couple decades so it's battle tested and has proven its merits. Look at WhatsApp, 1-2 million connections per server, 400 million users ~ 30 engineers.

Pro - "Realtime" / pubsub: Phoenix also ships with a realtime layer that we call "Channels" for doing pubsub/realtime events to clients. Our goal is to make building realtime applications as straight forward as building REST endpoints. We include a `phoenix.js` browser client, but we are targeting multiplatorm support and have a working Swift client internally. So Phoenix aims to go beyond a typical "Web Framework". The Web is more than just html apps (but Phoenix excels as just that). Imagine a iOS game publishing on Phoenix channels to other iOS clients, and a Web front-end reporting world events, player lists, etc. Phoenix can power all of it. By virtue of the Erlang VM, we also get cluster support For Free. You can run multiple phoenix nodes on a cluster and PubSub Just Works. No need for redis in b/w or worrying about sticky sessions. Concurrency in Elixir is location transparent. A process is a process regardless of machine it runs on in a cluster.

Cons - Packages, Training: My goals are to wholesale replace all my Rails work with Phoenix, but obviously we have a ways to go. The main cons are lack of off-the-shelf community packages like in Rails land. We are also not yet at 1.0, so you have to be willing to put up with breaking changes until we're ready to brand a 1.0 release next year. I'm using it for prod systems, but this is an upfront reality as we march towards 1.0. Other cons would be having to train folks new to Elixir, which often means learning a number of new paradigms at the same time. There's a helpful Elixir community for newcomers, but it will take more upfront work to get up to speed if you're coming from an OO background.

Hope that helps. Ruby folks might find my RailsConf Elixir workshop helpful as a place to get started in Elixir: http://www.confreaks.com/videos/3488-railsconf-workshop-all-...

freenode #elixir-lang irc is also a great resource for questions.

Nice work! I would also recommend stealing as much good stuff as you can from ChicagoBoss. It has the same RoR roots and great overall architecture. Thanks for this.

Could you please explain how PubSub in a cluster "Just Works"? How does it share subscriptions/channels between nodes?

I created a distributed PubSub for the Scala/Akka/Play toolchain a while ago so just wondering how it compares: https://github.com/alexanderjarvis/dubsub

We use Erlang's pg2 module internally to handle the distributed process groups and build a layer on top to handle broadcasts and node failover.

It would be awesome if you could publish the pubsub stuff as a separate library, for apps that don't need/want Phoenix. Possible?

Is there much benefit in using Phoenix for the server for a SPA where 95% is API routes, over using Plug directly? I guess it might make adding websocket services easier in future? (I've been very impressed with Plug/Ecto, just wondering if moving over to Phoenix while not too entrenched would be worthwhile.)

Even if you aren't using Channels or HTML views, you still get the nice features like Router pipelines, JSON Views, code reloading in development for "Refresh Driven Dev", and our Controllers, which provides a number of nice features on to of Plug, like content negotiation. Phoenix Views are really nice for JSON composition and if you ever need to start serving other content like HTML, you'll be all set. Plug is a fine choice, but you'll have to roll a lot more code yourself. If are planning WS related features in the future, Phoenix will make that a first-class experience, where Plug you'll have to dip directly into the underlying webserver adapter.

Thanks, that's useful, I'll take a look at moving across.

I have one question regarding how the Router works.

I worked with the new Node.js framework called Koa.js. It has an interesting way of dealing with middlewares (would be Plug in Elixir world, I assume). Request and response are passed through the middleware chain downstream, and each of them can take the response from previous middleware(s), modify it if needed, and pass to the next.

Either the response reaches the last middleware, or one of middlewares returns immediately, the response goes back "upstream" through the middlewares again. Then it is replied to the client.

During the flow, each middleware can also yield to the next one, so that it can handle the updated response when it goes upstream.

Imagine the cache middleware. Request comes in, this middleware checks if there is a cache of that request. If not, it yields to the next middlewares that will retrieve and transform the data, then cache the response body before returning to client.

For me, this flow offers a lot of flexibility in request and response handling. Is there anything similar to Phoenix?

From what I understand, once a Plug chooses to reply, the response ends at that Plug.

Yes, this is similar to Plug, but we only have a "connection". There is no distinction b/w request/response. A series of Plugs form a transformation layer on the connection where plug middleware can transform the connection, send a response etc. "Yielding to the next plug" is just a matter of returning the connection. There is no explicit yield. You either halt the connection (don't invoke further plugs) or continue the stack by returning the conn unhalted. Where your "upstream" concept fits is a connection can have callbacks bound that are invoked just before the response is sent, this is where a cache plug would cache the response. Plug avoids the issue of separating request/response because for things like streaming, sending a response does not mean that the stack is done with the request. Rack has this issue with streaming and José put a great deal of thought into Plug around the lessoned learned from Rack style APIs. You can read about his thoughts here: http://blog.plataformatec.com.br/2012/06/why-your-web-framew...

> From what I understand, once a Plug chooses to reply, the response ends at that Plug.

In Phoenix, we halt the connection when you use most of our functions that send a response, because there is little you can do afterwards. The Plug response API itself never halts when a response is sent.

Thank for explaining. Is there a document of all available connection's life cycle hooks somewhere I can lookup? And can different Plugs attach different callback to same hook?

Right now, the Plug repo and docs is the best resource. Yep, different plugs can attach any number of `register_before_send` callbacks on the connection.

I just hope that Phoenix sticks it out for the long run. Other Elixir frameworks like Sugar and Dynamo are nearly dead by now.

Secondly, I hope that the original dev team sticks around too. The Erlang web framework - ChicagoBoss - has had its development slowed down ever since Evan Miller stepped down.

Phoenix is here to stay. My first commit was a year ago, with the goal of web framework to replace all my Ruby work, both for clients and personal projects. Since then, I've spent hundreds of hours on the framework, spoke about it at ElixirConf, and started building prod systems with it. We've also had the pleasure of José Valim joining the phoenix-core team and contributing some really great work. We're just getting started.

What is the reason for requiring the absolute latest minor tick releases? Elixir is pretty cool, but the default solution to installing it (from the erlang-solutions repo) gives me a version that doesn't work with Phoenix. I don't really want to build the language from source, as that makes deployment just that much harder and error prone.

Hrm, unless I am missing something, Phoenix requires Elixir 1.0.2 which is available in Erlang Solutions sources? https://www.erlang-solutions.com/downloads/download-elixir

The reason though is that Elixir 1.0.2 includes some bug fixes that affects Phoenix in development.

Version managers do exist for Elixir to make upgrading Elixir easier. One such is exenv[0] and elixir-build[1] which should be familiar to you in use if you've ever used rbenv and ruby-build. If you're on OS X, homebrew usually gets updated with the latest version of Elixir minutes after a release happens.

0 - https://github.com/mururu/exenv

1 - https://github.com/mururu/elixir-build

I use kerl - https://github.com/yrashk/kerl and kiex - https://github.com/taylor/kiex. They also work very well.

I used exenv to get new Elixir version, it's very useful for me.

How does Phoenix compare to WebMachine (Erlang) and Liberator (Clojure)? Specifically does it have similar decision graph tracing.

Is some form of hypermedia supported or built in? If not, is it planned?

These may be answered in the presentation. I hope to watch it soon.

Phoenix is different to WebMachine and Liberator as it is much closer to frameworks like Rails, Django and Play. There is no plan for hypermedia built-in support for 1.0.

What is it? Elixir Web Framework means nothing to me.

Elixir is a programming language that is on the Erlang's VM.

Like Scala being on the JVM.

Web Framework is just that a web framework.

From what the creator have commented on, it seems like it will be influenced by Ruby on Rails framework.

Is there any way create a Phoenix add-ons for my Rails app? It would be great to use Phoenix to handle the real-time parts of the app without having to walk away from all of our working Rails code.

This doesn't answer your question, but you may find it interesting - an easy way to process Sidekiq jobs made in Ruby using Elixir: http://www.neo.com/2014/08/11/ruby-elixir-polyglottin-ftw

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact