9 ms·

Phoenix – Elixir Web Framework

273 points by areski 12y ago

chrismccord 12y ago
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-the-phoenix-building-an-elixir-web-framework http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-...
- saosebastiao 12y ago
  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.
  - rubiquity 12y ago
    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 https://github.com/mururu/exenv 1 - https://github.com/mururu/elixir-build https://github.com/mururu/elixir-build
    - darkof 12y ago
      I use kerl - https://github.com/yrashk/kerl https://github.com/yrashk/kerl and kiex - https://github.com/taylor/kiex https://github.com/taylor/kiex. They also work very well.
    - ma2ge 12y ago
      I used exenv to get new Elixir version, it's very useful for me.
  - josevalim 12y ago
    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 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.
- vmind 12y ago
  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.)
  - chrismccord 12y ago
    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.
    - vmind 12y ago
      Thanks, that's useful, I'll take a look at moving across.
- lectrick 12y ago
  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...)
  - chrismccord 12y ago
    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-aboard-the-elixir-express http://www.confreaks.com/videos/3488-railsconf-workshop-all-... freenode #elixir-lang irc is also a great resource for questions.
- encloser 12y ago
  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.
  - josevalim 12y ago
    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.
- andyl 12y ago
  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.
  - shadeless 12y ago
    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 http://www.neo.com/2014/08/11/ruby-elixir-polyglottin-ftw
- deathtrader666 12y ago
  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.
  - chrismccord 12y ago
    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.
- sntran 12y ago
  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.
  - chrismccord 12y ago
    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-framework-should-not-adopt-rack-api/ 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.
- skybrian 12y ago
  What is it? Elixir Web Framework means nothing to me.
  - digitalzombie 12y ago
    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.
rozap 12y ago
My experience with Phoenix was super positive. I built https://www.vuln.pub https://www.vuln.pub with it while learning Elixir (no erlang experience..) and it couldn't have been easier. Everyone was very helpful on IRC if I did run into problems, and the framework itself is extremely well documented and the source is quite readable. Definitely would recommend trying it out if you haven't. It was a breath of fresh air from where I was in node.js/python land.
- lectrick 12y ago
  What did you like about it vs. building the same thing on the Rails stack, assuming you are/were a Rails guy? Also, how's your test suite? :)
  - rozap 12y ago
    I have no rails experience, but have written a lot of python stuff in django and flask, and some node stuff in express. I guess compared to django (and rails..), it's absolutely a smaller framework, so it's easier to reason about what's going on, and when you don't understand the source is much easier to follow. Diving into the django source to figure out a problem was a nightmare. In terms of actually using it, the biggest strength is the concurrency model. It handles blocking much better than rails or django where you typically have a fixed number of workers, and if you block and fill up those workers then you're SOL. Yea there are workarounds here, but they're pretty ugly. python and ruby don't really have nice solutions for this, which brings us to node. In node, you always need to be actively thinking about handling async IO with callbacks or promises or whatever, and you can quickly end up in callback hell if you aren't careful. In elixir (and erlang), BEAM handles all that hard stuff. The result is your code is easier to write and read. Every phoenix http request is in its own elixir process. There's no weird request context like you get in flask, no way to abuse request state, and no callbacks to deal with. You can block a process all you want and throughput will be the same. The code looks like it executes sequentially, even though it doesn't. For a small app like the one I wrote, it also has the advantage of being able to start a bunch of little services in the background to handle longer running tasks (which would typically be handled by a message queue with django/rails) and they're super easy to deal with since it's just standard elixir process messaging. These services handle things like performance logging, emailing, as well as (in the case of my app) looking for vulnerability disclosures and resolving them to package specs. Anyway, sorry for the rambling response, but I hope it gives a general overview of why elixir and phoenix made building something way more pleasant than what I'm used to. Why do you ask about the test suite? Did you find a bug? :)
rubiquity 12y ago
It's really awesome how Phoenix has come a really long way in a really short period of time. Chris and José (and many others) do an excellent job of carefully considering features and how those features get implemented. While many refer to Phoenix as a "web framework" I don't think of it that way in the traditional sense of web frameworks like Rails. I find it closer to a "web library" that does an excellent job of handling Web concerns such as routing, WebSockets, rendering HTML/JSON and internationalization. I think this is a good thing in this day and age of having very diverse model layers. If you have time and want to see a very well run open source project in action, I recommend you read through present and past discussions on the Phoenix GitHub project: https://github.com/phoenixframework/phoenix/issues https://github.com/phoenixframework/phoenix/issues
polskibus 12y ago
Is providing helpers for authentication and authorization (for example like ASP.NET MVC attributes) anywhere on the roadmap? It would be helpful not to reimplement authentication routines from scratch in every project.
- chrismccord 12y ago
  There are no plans to provide authentication, but since the Phoenix Router and Controllers are just Plugs, we should se e the community produce a handful of first-class auth solutions as things mature. I don't think a generic auth solution that works for everyone is easily done and would prefer third-party packages. The nice thing about Plug is these solutions should be relatively easy to add to yours stack.
  - Ixiaus 12y ago
    What Python's Pyramid web-framework did well in that area was to provide the scaffolding around Access Control Lists in the application. You figured out authentication and provided a really simple function and DB table for resolving roles and permissions and the app did the rest. I think most frameworks should follow that model: provide a flexible ACL system but let the developer figure out auth.
    - chrismccord 12y ago
      Interesting. I'll take a look at the ACL system. We're planning a Resource protocol and something along those lines could integrate nicely.
      - Ixiaus 12y ago
        It worked particularly well for Pyramid with it's resource hierarchy object-model. The ACL would cascade down the tree and as it was traversed it could pattern match the permissions against the tree-node acl. I actually think the model it's better suited to a functional language. I'm working on a similar extension to the Haskell snap framework.
alinenache 12y ago
http://waltherpragerandphilosophy1.blogspot.ro/2013/02/technical-illusion.html http://waltherpragerandphilosophy1.blogspot.ro/2013/02/techn...
klibertp 12y ago
I tried using Phoenix for a simple web app I wrote last month. It was a couple of static html/js files and a single WebSocket connection, so nothing fancy. Unfortunately, I found the documentation lacking, and the framework much too "magical" for me to quickly understand and make use of. I have no experience with Rails but rather with Django, so that may explain a lot. Anyway, in the end I used Erlang and Cowboy instead. I checked out Cowboy from github master which is "almost 2.0" now, and I had no problems at all setting basic project up. Defining routes was straightforward and explicit (which I like), upgrading connection to websocket and handling incoming data was simple and explicit too. I added eredis and jiffy to the project and that's basically it, it did everything I wanted it to do splendidly, with little magic and very little overhead. Now, I know Erlang much better than Elixir, and I worked with Cowboy before and I needed to make this app quickly, which resulted in me not spending too much time on learning Phoenix. Between controllers, routes, views and channels I got an impression that Phoenix has too many moving parts and that it would take me too much time to fully understand what's going on. Especially because I really didn't need most of these, just a static file server and a single WebSocket. However, I see Phoenix potential for more complex projects, where investing the time to learn it is going to be worth it. It looks like Phoenix provides an awful lot of conveniences and makes a project much better structured than my "a couple of files in a single directory" approach. I guess what I want to say is that I almost used Phoenix this time and that I would probably use it if it had better docs - especially a solid tutorial(s) for use cases similar to mine. And that, while I didn't use it this time around, I'm certainly going to keep an eye on it and consider it next time I have to write something similar. It looks very promising and - like Elixir itself - very interesting, I hope for it to only grow in the future :)
- therockhead 12y ago
  Regarding documention, did you see the following guides https://github.com/lancehalvorsen/phoenix-guides https://github.com/lancehalvorsen/phoenix-guides ?
  - klibertp 12y ago
    No, and after a quick look at them I see that they'd help. Would be nice to have this mentioned in the project main readme under "Documentation" - do you know why it isn't there (yet)?
davidw 12y ago
I don't see "database" mentioned anywhere on that page. What direction are you going to head in with that?
- Havvy 12y ago
  You can use whatever database `app` you want, such as Ecto.
- klibertp 12y ago
  It will be a long time before you will actually need something other than Mnesia :)
- pmontra 12y ago
  I used Ecto in Phoenix to connect to PostgreSQL. I didn't try it to connect to anything else but I understand that it should work with most DBs.
- joshsharp 12y ago
  Ecto and PostgreSQL seems the most mature option, though there's a Redis library and of course Mnesia. I haven't been able to find any support for MySQL.
  - HashNuke 12y ago
    Someone was trying to add MySQL support - https://github.com/elixir-lang/ecto/pull/193 https://github.com/elixir-lang/ecto/pull/193 It is possible to write an Ecto adapter for Riak, with some workarounds. I tried it once, but the motivation to continue...
- chrismccord 12y ago
  We don't ship with any DB layer today, but Ecto is the defacto choice for sql. We are planning to include a Resource Protocol, so it should be very easy to bring your own DB/model layer and still get all the nice conventional route builders, forms, etc.
- bratsche 12y ago
insertion 12y ago
This looks pretty elegant, but it's a shame that Elixir uses the Ruby-style multi-line code blocks with do end. Looking at those code examples, 'end' take up around 25% of the lines with code. Does anyone know if they considered taking the Python approach? Would be curious to hear the arguments behind the decision. I've noticed that most people seem to favor the Python approach after trying it, but that it's rarely used in new languages.
- codexon 12y ago
  I absolutely agree with this. Having end clutters up the screen. Many people dislike python whitespace though but I think brackets are still better than end.
- adamkittelson 12y ago
  Here's a link to a discussion on the mailing list that touches on why Python-style significant whitespace wasn't used: https://groups.google.com/forum/#!topic/elixir-lang-talk/u6PXqsfX1HQ https://groups.google.com/forum/#!topic/elixir-lang-talk/u6P...
codexon 12y ago
Is Elixir production ready now?
- MCRed 12y ago
  It's been in production at one company since January 2014.
- Havvy 12y ago
  Elixir is currently at v.1.0.2 and following SemVer. I'm guessing that counts as production ready by your definition.
joshsharp 12y ago
I've been following Elixir closely and recently built a super-simple chat app using Phoenix and websockets. I agree with other comments here that the docs could use some work, and as I also come from a Django background, rather than Rails, I found it a little magical for my tastes. However, once I understood how things go together, it was pretty trivial to get up and running. The included phoenix.js library makes the websocket pub/sub stuff ridiculously easy. I'm really interested to see where Elixir is going, and to try building something real with it. I'll probably use Phoenix, just because it's the most active, mature framework. (I like the look of Dynamo - https://github.com/dynamo/dynamo https://github.com/dynamo/dynamo - but not sure how active it is.)
- notduncansmith 12y ago
  According to the Dynamo readme: > Dynamo is currently in maintenance mode for those who are already using it in production. Developers who seek for an actively developed framework are recommended to look for other alternatives in Elixir.
lobster_johnson 12y ago
Elixir is great. I just wish its syntax was more appealing; some of the design choices are a little idiosynchratic. Using "do..end" is natural in Ruby for blocks, but Elixir uses it for everything, and it looks pretty odd: Enum.map [1, 2, 3], fn(x) -> x * 2 end or: receive do {:hello, msg} -> msg {:world, msg} -> "won't match" end The "do" syntax is in fact syntactic sugar for keyword arguments, which is suprising and a little disappointing, especially when you realize that constructs like "if", "case" and "receive" are in fact implemented as functions. Sacrificing syntactic elegance for consistency ("everything is a function") might be clever, but is it an improvement over hard-wiring this stuff into the language as first-class keywords? I personally don't think so. It's a minor point, and not major enough to make me not use Elixir, but when someone goes this far in putting a nicer skin around Erlang, it's disappointing to find newly-invented blemishes that are as weird as the ones it aimed to smooth over in the first place.
- Cyranix 12y ago
  Does that syntactic choice make it easier to understand the connection between normal expressions and their quoted forms? (http://elixir-lang.org/getting_started/meta/1.html http://elixir-lang.org/getting_started/meta/1.html) As a newbie coming into Elixir without either Ruby or Erlang background, I didn't find anything in the syntax to be a real pain point (although understanding optional parenthesis usage in CoffeeScript did help).
  - lobster_johnson 12y ago
    Sure, if everything (including control statements like "if" and "case") is a function, it means the underlying data structure is simpler. That design in itself doesn't preclude other syntaxes such as a more familiar brace syntax.
    - josevalim 12y ago
      The language designer here. There is literally no escape from such perception coming from somewhere regardless of the choice. :) I have mentioned before this is often the most unrewarding aspect of designing a language because, it doesn't matter what you do, you will always get an opposing opinion. Here are some examples of what I have heard or read multiple times throughout the years: * Using the brace syntax is seen as catering to common languages (like C and Java) which would arguably cause a lot of confusion when added on top of a functional language * Going with Lisp is always a matter of love or hate. Some people will love it and some people is going to really hate it * The same with space-based indentation. A lot of people praise its conciseness, a lot of people curse the code being extremely hard to move around (this was honestly my second choice but it would get complex inside quoted expressions) * The do-end blocks gets some praise for being readable (less punctuation characters) but also a bad rap for being verbose To be clear, I am not calling you out, the point is exactly that everyone will have their preferences and if I was not writing this comment to you, I'd definitely be writing it to someone else. :)
dynjo 12y ago
We are a pretty big Rails shop (30+) devs and are getting pretty excited about Elixir. We are currently writing a series of blog posts about our Elixir journey, first one here http://blog.oozou.com/why-we-are-excited-about-elixir/ http://blog.oozou.com/why-we-are-excited-about-elixir/
jacktang 12y ago
Wow, glad to see the news. Now we just embed rails web application into cowboy server by using cowboy-rack adapter.

273 points by areski 12y ago

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-the-phoenix-building-an-elixir-web-framework http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-...

saosebastiao 12y ago
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.
- rubiquity 12y ago
  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 https://github.com/mururu/exenv 1 - https://github.com/mururu/elixir-build https://github.com/mururu/elixir-build
  - darkof 12y ago
    I use kerl - https://github.com/yrashk/kerl https://github.com/yrashk/kerl and kiex - https://github.com/taylor/kiex https://github.com/taylor/kiex. They also work very well.
  - ma2ge 12y ago
    I used exenv to get new Elixir version, it's very useful for me.
- josevalim 12y ago
  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 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.
vmind 12y ago
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.)
- chrismccord 12y ago
  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.
  - vmind 12y ago
    Thanks, that's useful, I'll take a look at moving across.
lectrick 12y ago
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...)
- chrismccord 12y ago
  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-aboard-the-elixir-express http://www.confreaks.com/videos/3488-railsconf-workshop-all-... freenode #elixir-lang irc is also a great resource for questions.
encloser 12y ago
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.
- josevalim 12y ago
  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.
andyl 12y ago
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.
- shadeless 12y ago
  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 http://www.neo.com/2014/08/11/ruby-elixir-polyglottin-ftw
deathtrader666 12y ago
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.
- chrismccord 12y ago
  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.
sntran 12y ago
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.
- chrismccord 12y ago
  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-framework-should-not-adopt-rack-api/ 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.
skybrian 12y ago
What is it? Elixir Web Framework means nothing to me.
- digitalzombie 12y ago
  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.

rozap 12y ago

My experience with Phoenix was super positive. I built https://www.vuln.pub https://www.vuln.pub with it while learning Elixir (no erlang experience..) and it couldn't have been easier. Everyone was very helpful on IRC if I did run into problems, and the framework itself is extremely well documented and the source is quite readable. Definitely would recommend trying it out if you haven't. It was a breath of fresh air from where I was in node.js/python land.

lectrick 12y ago
What did you like about it vs. building the same thing on the Rails stack, assuming you are/were a Rails guy? Also, how's your test suite? :)
- rozap 12y ago
  I have no rails experience, but have written a lot of python stuff in django and flask, and some node stuff in express. I guess compared to django (and rails..), it's absolutely a smaller framework, so it's easier to reason about what's going on, and when you don't understand the source is much easier to follow. Diving into the django source to figure out a problem was a nightmare. In terms of actually using it, the biggest strength is the concurrency model. It handles blocking much better than rails or django where you typically have a fixed number of workers, and if you block and fill up those workers then you're SOL. Yea there are workarounds here, but they're pretty ugly. python and ruby don't really have nice solutions for this, which brings us to node. In node, you always need to be actively thinking about handling async IO with callbacks or promises or whatever, and you can quickly end up in callback hell if you aren't careful. In elixir (and erlang), BEAM handles all that hard stuff. The result is your code is easier to write and read. Every phoenix http request is in its own elixir process. There's no weird request context like you get in flask, no way to abuse request state, and no callbacks to deal with. You can block a process all you want and throughput will be the same. The code looks like it executes sequentially, even though it doesn't. For a small app like the one I wrote, it also has the advantage of being able to start a bunch of little services in the background to handle longer running tasks (which would typically be handled by a message queue with django/rails) and they're super easy to deal with since it's just standard elixir process messaging. These services handle things like performance logging, emailing, as well as (in the case of my app) looking for vulnerability disclosures and resolving them to package specs. Anyway, sorry for the rambling response, but I hope it gives a general overview of why elixir and phoenix made building something way more pleasant than what I'm used to. Why do you ask about the test suite? Did you find a bug? :)

rubiquity 12y ago

It's really awesome how Phoenix has come a really long way in a really short period of time. Chris and José (and many others) do an excellent job of carefully considering features and how those features get implemented. While many refer to Phoenix as a "web framework" I don't think of it that way in the traditional sense of web frameworks like Rails. I find it closer to a "web library" that does an excellent job of handling Web concerns such as routing, WebSockets, rendering HTML/JSON and internationalization. I think this is a good thing in this day and age of having very diverse model layers. If you have time and want to see a very well run open source project in action, I recommend you read through present and past discussions on the Phoenix GitHub project: https://github.com/phoenixframework/phoenix/issues https://github.com/phoenixframework/phoenix/issues

polskibus 12y ago

Is providing helpers for authentication and authorization (for example like ASP.NET MVC attributes) anywhere on the roadmap? It would be helpful not to reimplement authentication routines from scratch in every project.

chrismccord 12y ago
There are no plans to provide authentication, but since the Phoenix Router and Controllers are just Plugs, we should se e the community produce a handful of first-class auth solutions as things mature. I don't think a generic auth solution that works for everyone is easily done and would prefer third-party packages. The nice thing about Plug is these solutions should be relatively easy to add to yours stack.
- Ixiaus 12y ago
  What Python's Pyramid web-framework did well in that area was to provide the scaffolding around Access Control Lists in the application. You figured out authentication and provided a really simple function and DB table for resolving roles and permissions and the app did the rest. I think most frameworks should follow that model: provide a flexible ACL system but let the developer figure out auth.
  - chrismccord 12y ago
    Interesting. I'll take a look at the ACL system. We're planning a Resource protocol and something along those lines could integrate nicely.
    - Ixiaus 12y ago
      It worked particularly well for Pyramid with it's resource hierarchy object-model. The ACL would cascade down the tree and as it was traversed it could pattern match the permissions against the tree-node acl. I actually think the model it's better suited to a functional language. I'm working on a similar extension to the Haskell snap framework.

alinenache 12y ago

http://waltherpragerandphilosophy1.blogspot.ro/2013/02/technical-illusion.html http://waltherpragerandphilosophy1.blogspot.ro/2013/02/techn...

klibertp 12y ago

I tried using Phoenix for a simple web app I wrote last month. It was a couple of static html/js files and a single WebSocket connection, so nothing fancy. Unfortunately, I found the documentation lacking, and the framework much too "magical" for me to quickly understand and make use of. I have no experience with Rails but rather with Django, so that may explain a lot. Anyway, in the end I used Erlang and Cowboy instead. I checked out Cowboy from github master which is "almost 2.0" now, and I had no problems at all setting basic project up. Defining routes was straightforward and explicit (which I like), upgrading connection to websocket and handling incoming data was simple and explicit too. I added eredis and jiffy to the project and that's basically it, it did everything I wanted it to do splendidly, with little magic and very little overhead. Now, I know Erlang much better than Elixir, and I worked with Cowboy before and I needed to make this app quickly, which resulted in me not spending too much time on learning Phoenix. Between controllers, routes, views and channels I got an impression that Phoenix has too many moving parts and that it would take me too much time to fully understand what's going on. Especially because I really didn't need most of these, just a static file server and a single WebSocket. However, I see Phoenix potential for more complex projects, where investing the time to learn it is going to be worth it. It looks like Phoenix provides an awful lot of conveniences and makes a project much better structured than my "a couple of files in a single directory" approach. I guess what I want to say is that I almost used Phoenix this time and that I would probably use it if it had better docs - especially a solid tutorial(s) for use cases similar to mine. And that, while I didn't use it this time around, I'm certainly going to keep an eye on it and consider it next time I have to write something similar. It looks very promising and - like Elixir itself - very interesting, I hope for it to only grow in the future :)

therockhead 12y ago
Regarding documention, did you see the following guides https://github.com/lancehalvorsen/phoenix-guides https://github.com/lancehalvorsen/phoenix-guides ?
- klibertp 12y ago
  No, and after a quick look at them I see that they'd help. Would be nice to have this mentioned in the project main readme under "Documentation" - do you know why it isn't there (yet)?

davidw 12y ago

I don't see "database" mentioned anywhere on that page. What direction are you going to head in with that?

Havvy 12y ago
You can use whatever database `app` you want, such as Ecto.
klibertp 12y ago
It will be a long time before you will actually need something other than Mnesia :)
pmontra 12y ago
I used Ecto in Phoenix to connect to PostgreSQL. I didn't try it to connect to anything else but I understand that it should work with most DBs.
joshsharp 12y ago
Ecto and PostgreSQL seems the most mature option, though there's a Redis library and of course Mnesia. I haven't been able to find any support for MySQL.
- HashNuke 12y ago
  Someone was trying to add MySQL support - https://github.com/elixir-lang/ecto/pull/193 https://github.com/elixir-lang/ecto/pull/193 It is possible to write an Ecto adapter for Riak, with some workarounds. I tried it once, but the motivation to continue...
chrismccord 12y ago
We don't ship with any DB layer today, but Ecto is the defacto choice for sql. We are planning to include a Resource Protocol, so it should be very easy to bring your own DB/model layer and still get all the nice conventional route builders, forms, etc.
bratsche 12y ago

insertion 12y ago

This looks pretty elegant, but it's a shame that Elixir uses the Ruby-style multi-line code blocks with do end. Looking at those code examples, 'end' take up around 25% of the lines with code. Does anyone know if they considered taking the Python approach? Would be curious to hear the arguments behind the decision. I've noticed that most people seem to favor the Python approach after trying it, but that it's rarely used in new languages.

codexon 12y ago
I absolutely agree with this. Having end clutters up the screen. Many people dislike python whitespace though but I think brackets are still better than end.
adamkittelson 12y ago
Here's a link to a discussion on the mailing list that touches on why Python-style significant whitespace wasn't used: https://groups.google.com/forum/#!topic/elixir-lang-talk/u6PXqsfX1HQ https://groups.google.com/forum/#!topic/elixir-lang-talk/u6P...

codexon 12y ago

Is Elixir production ready now?

MCRed 12y ago
It's been in production at one company since January 2014.
Havvy 12y ago
Elixir is currently at v.1.0.2 and following SemVer. I'm guessing that counts as production ready by your definition.

joshsharp 12y ago

I've been following Elixir closely and recently built a super-simple chat app using Phoenix and websockets. I agree with other comments here that the docs could use some work, and as I also come from a Django background, rather than Rails, I found it a little magical for my tastes. However, once I understood how things go together, it was pretty trivial to get up and running. The included phoenix.js library makes the websocket pub/sub stuff ridiculously easy. I'm really interested to see where Elixir is going, and to try building something real with it. I'll probably use Phoenix, just because it's the most active, mature framework. (I like the look of Dynamo - https://github.com/dynamo/dynamo https://github.com/dynamo/dynamo - but not sure how active it is.)

notduncansmith 12y ago
According to the Dynamo readme: > Dynamo is currently in maintenance mode for those who are already using it in production. Developers who seek for an actively developed framework are recommended to look for other alternatives in Elixir.

lobster_johnson 12y ago

Elixir is great. I just wish its syntax was more appealing; some of the design choices are a little idiosynchratic. Using "do..end" is natural in Ruby for blocks, but Elixir uses it for everything, and it looks pretty odd: Enum.map [1, 2, 3], fn(x) -> x * 2 end or: receive do {:hello, msg} -> msg {:world, msg} -> "won't match" end The "do" syntax is in fact syntactic sugar for keyword arguments, which is suprising and a little disappointing, especially when you realize that constructs like "if", "case" and "receive" are in fact implemented as functions. Sacrificing syntactic elegance for consistency ("everything is a function") might be clever, but is it an improvement over hard-wiring this stuff into the language as first-class keywords? I personally don't think so. It's a minor point, and not major enough to make me not use Elixir, but when someone goes this far in putting a nicer skin around Erlang, it's disappointing to find newly-invented blemishes that are as weird as the ones it aimed to smooth over in the first place.

Cyranix 12y ago
Does that syntactic choice make it easier to understand the connection between normal expressions and their quoted forms? (http://elixir-lang.org/getting_started/meta/1.html http://elixir-lang.org/getting_started/meta/1.html) As a newbie coming into Elixir without either Ruby or Erlang background, I didn't find anything in the syntax to be a real pain point (although understanding optional parenthesis usage in CoffeeScript did help).
- lobster_johnson 12y ago
  Sure, if everything (including control statements like "if" and "case") is a function, it means the underlying data structure is simpler. That design in itself doesn't preclude other syntaxes such as a more familiar brace syntax.
  - josevalim 12y ago
    The language designer here. There is literally no escape from such perception coming from somewhere regardless of the choice. :) I have mentioned before this is often the most unrewarding aspect of designing a language because, it doesn't matter what you do, you will always get an opposing opinion. Here are some examples of what I have heard or read multiple times throughout the years: * Using the brace syntax is seen as catering to common languages (like C and Java) which would arguably cause a lot of confusion when added on top of a functional language * Going with Lisp is always a matter of love or hate. Some people will love it and some people is going to really hate it * The same with space-based indentation. A lot of people praise its conciseness, a lot of people curse the code being extremely hard to move around (this was honestly my second choice but it would get complex inside quoted expressions) * The do-end blocks gets some praise for being readable (less punctuation characters) but also a bad rap for being verbose To be clear, I am not calling you out, the point is exactly that everyone will have their preferences and if I was not writing this comment to you, I'd definitely be writing it to someone else. :)

dynjo 12y ago

We are a pretty big Rails shop (30+) devs and are getting pretty excited about Elixir. We are currently writing a series of blog posts about our Elixir journey, first one here http://blog.oozou.com/why-we-are-excited-about-elixir/ http://blog.oozou.com/why-we-are-excited-about-elixir/

jacktang 12y ago

Wow, glad to see the news. Now we just embed rails web application into cowboy server by using cowboy-rack adapter.