
Phoenix – Elixir Web Framework - areski
https://github.com/phoenixframework/phoenix
======
chrismccord
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-...](http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-the-
phoenix-building-an-elixir-web-framework)

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

------
klibertp
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 :)

~~~
sntran
This. I can not put my words any better than this.

I used to dislike Rails, since it seemed to be too much abstraction that would
require time to learn. I now have the same feeling about Phoenix. I could put
up a simple web app quickly with Erlang and Cowboy. With Phoenix, I needed to
read documents and the source code to figure out what all the imports are
doing.

~~~
krick
For me it's not even about "time to learn", but the fact that I never can be
sure I know how something like this works. Even that little detail about how
`resources` automatically defines so many routes… yeah, it's kinda convenient,
but I would be more comfortable if I'd have _all_ of my routes explicitly
defined somewhere, at least in a framework with scaffolding. When an app
written like that grows, and I'm not the only developer, and that guy before
me was clearly using drugs — well, that really becomes scary much quicker than
in a simple Flask-style framework.

~~~
josevalim
Curiosity: is that a concern only with routes? Or would you also like to have
a explicit control of which middleware you are using too?

Because if the latter, it feels like a web framework isn't for you. But you
should definitely consider Plug ([http://github.com/elixir-
lang/plug](http://github.com/elixir-lang/plug)), which has all the pieces and
you just need to put them together (a simple router, a bunch of "middleware",
etc).

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

~~~
lectrick
> Did you find a bug? :)

No, but there may be one already, lying hidden, unless you have a good test
suite haha

~~~
rozap
I have a lot of tests, but tests and bugs can and do live in harmony together.

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

------
dynjo
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/)

------
lobster_johnson
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
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
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
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. :)

~~~
lobster_johnson
Of course; you can't make everyone happy all the time.

However, it's quite obvious that you are hugely influenced by Ruby's syntax.
What I don't understand is why, in copying Ruby's overall flavour of syntax,
you decided to make it a little worse.

My hypothesis is that you discovered that this syntax allowed an elegant,
unifying structure to the internal implementation, which is fine — but as a
user, it comes across as an annoying wart. The parser should know perfectly
well that after "def" comes a function name, so why does it need the "do" to
demarcate the function body? It would have been just as ugly in Ruby, which
goes for terseness in the common case (eg., "if" can take a "then").

Criticisms aside, I should add that this is the only thing so far that has
annoyed me about Elixir.

~~~
lancehalvorsen
My $0.02.

Elixir's do/end blocks actually enhance the syntax it inherits from Ruby by
making it very, very consistent. Defining any type of entity takes a do/end
block - def, defmodule, defmacro, defprotocol, defimpl, and probably some that
I have forgotten.

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

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

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

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

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

~~~
adamkittelson
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/u6P...](https://groups.google.com/forum/#!topic/elixir-lang-
talk/u6PXqsfX1HQ)

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

------
codexon
Is Elixir production ready now?

~~~
Havvy
Elixir is currently at v.1.0.2 and following SemVer. I'm guessing that counts
as production ready by your definition.

