Minimum Viable Phoenix

http://www.petecorey.com/blog/2019/05/20/minimum-viable-phoenix/

by pcorey • 7 years ago

174 27 7 years ago

petecorey.com

seeker61• 7 years ago

Another framework. May merciful Providence deliver us.

fouc• 7 years ago

Hmm? You haven't heard of Phoenix/Elixir? It's mentioned on HN fairly often.

ncmncm• 7 years ago

No, I haven't.

It's comical how the FA jumps right in assuming you know what it is, what it's for, and why you should care about the first two -- comical in a good way, for those of us who are happier not knowing.

I have a vague impression that Elixir has something to do with Erlang, and that is all I need to know, but that Phoenix has something to do with Elixir also wasn't mentioned right away.

verttii• 7 years ago

In all fairness it's been around for quite some time.

Moreover, the abundance of frameworks is not inherently a bad thing in my opinion. You don't need to learn it if it doesn't solve a problem for you after all.

theonething2• 7 years ago

I'm not agreeing with the GP's attitude about more frameworks. In fact, I really enjoy working with Phoenix and am glad the author(s) put in the hard work to build it.

But

You don't need to learn it if it doesn't solve a problem for you after all

is not true. I don't like React and I have to use it at work because that is what was chosen.

ramchip• 7 years ago

It’s the only framework with significant usage in Elixir. I don’t think one framework per language is excessive.

gojomo• 7 years ago

What is Phoenix?

eldenbishop• 7 years ago

Given there is an active Apache project called Phoenix (https://phoenix.apache.org) I think confusion here is warranted.

brightball• 7 years ago

Phoenix framework for the Elixir language. It's a web framework that leverages the natural concurrency and performance structure of the Erlang VM to handle both standard web development and web sockets.

That's the high altitude view.

In my professional opinion, Elixir and Phoenix also address the vast majority of short and long term issues that cause problems in projects without a negative impact on developer productivity. I'm a big believer it both. It's also got the perk of being so lightweight that there's almost no performance impact to using Phoenix instead of raw Elixir.

anthony_doan• 7 years ago

It's the most popular web framework for Elixir.

It's MVC-ish with the caveat that the Model is broken down into two files, context and schema.

From what I've gathered, it also offer three unique things compare to other framework (on top of the power of Erlang's VM).

1) Channel - easy integration with websocket

2) Presence - some advance thing that keep track of people online

3) LiveView - In beta-(ish?) It's a compromise between front end framework.

Do note I haven't had the chance to use 2 or 3. I did a little of 1 as a tutorial.

xtagon• 7 years ago

I really like this style of "literate commits".

drcongo• 7 years ago

This is a really great idea and well executed. Thank you.

dve2• 7 years ago

Ive been waiting for a tutorial like this. I am most likely doing something wrong, but sadly the code samples do not function as listed. Even cloning the repo and executing the commands listed only results in errors after the first step.

bluegene• 7 years ago

Author has provided the link to git repo in the article. All you have to do is,

git clone https://github.com/pcorey/minimum_viable_phoenix

mix deps.get

mix compile

mix phx.server

and you're good to go

dve2• 7 years ago

But the article is about phoenix from nothing. The reader is encouraged to work through each literate commit. Mix is not used until half way through the article.

yellowapple2• 7 years ago

I really wish this tutorial existed 5 years ago. It would've convinced me to actually try Phoenix instead of pulling up the official getting started guide only to scream internally at all the moving parts and start looking for alternatives.

But on the other hand, had this tutorial existed 5 years ago, I wouldn't have found Sugar (sugar-framework.github.io), and in turn wouldn't have started contributing to it, and in turn wouldn't have gone on the various deep dives into OTP and Plug necessary to comprehend it, let alone become one of the maintainers of it (albeit a rather neglectful one; this year's New Years Resolution is to address some longstanding bugs and get it back into a state where it could actually be to Phoenix as, say, Padrino is to Rails or Flask is to Django), so I guess it ain't all bad :)

txcwpalpha• 7 years ago

I hear ya. I think Hexdocs is great and I really appreciate the standardization of the Elixir community on one documentation format/site (though ironically it doesn't look like Sugar uses hexdocs), and in particular it's great at listing the various functions/modules etc within a package. However, I find it to be very lacking in terms of guide/tutorial content, and the Phoenix guide [1] is a great example of how it falls short. Compared to stuff like Django, which has amazing documentation, not just for the API, but also for guides that tell you how to do stuff like add routes, add authentication, do advanced queries [2], etc, the Phoenix guides are missing a lot.

It took me until I actually read an entire book about Phoenix (Programming Phoenix 1.4 [3], which I do recommend) before I actually got onboard with it. And while there's nothing wrong with reading a book, it is a significantly higher barrier to entry compared to something like Django or Rails, frameworks which a beginner can be taught the basics of in a single day just by browsing through the official documentation.

Now, with all that being said, I really do enjoy working in Phoenix now that I actually "broke through" that initial barrier of understanding. It and Elixir are very well thought out and pleasant to work with, even if they do take a little bit of extra effort to get started.

1: https://hexdocs.pm/phoenix/up_and_running.html

2: https://docs.djangoproject.com/en/2.2/contents/

3: https://pragprog.com/book/phoenix14/programming-phoenix-1-4

nickjj2• 7 years ago

However, I find it to be very lacking in terms of guide/tutorial content.

I found this to be the case too, but the community is very helpful on the forums and IRC. Everyone is really friendly and doesn't troll you for being new.

My way of learning so far has been to take in the docs to get the basics, stumble and fumble around on my own, look at code from open source projects, experiment with those things in my app and then as a last resort ask for help from one of the community outlets if I get legit stuck on something or have a question on best practices that I couldn't find online. It's been working out so far, but it's definitely a much more difficult road than binge watching 100 railscasts videos because every feature you want in your app has been designed in a production ready way and perfectly explained on video (that's how I learned Rails in about 3 months while building a quite involved app as my first "real" Rails app a number of years ago).

But like you said, I also came to the realization that Elixir and Phoenix might be one of the most well thought out combinations of software I've ever used for building web apps. Although at times, I do wish I could invent a time machine and fast forward 2 years to see where everything is at.

yellowapple2• 7 years ago

though ironically it doesn't look like Sugar uses hexdocs

Indeed it does not. I should probably fix that :)

(Much like how I also need to fix that for OTPCL...)

it is a significantly higher barrier to entry compared to something like Django or Rails

I don't know about Django (I tend to shy away from Python, and the little Python code I do voluntarily write is specifically for desktop apps via PyQt5), but I'd say Rails has just as steep of a learning curve, if not steeper (or at least it did when I was deep into Rails app development).

Now, with all that being said, I really do enjoy working in Phoenix now that I actually "broke through" that initial barrier of understanding.

Same here. I "broke through" via a much different path, though, going through Sugar then Plug then bottom-up into Phoenix. Turns out both Sugar and Phoenix stick very close to Plug (unsurprising, since they're both essentially collections of plugs arranged into MVC frameworks), so there's actually a surprising amount of compatibility between the two, both in terms of knowledge/semantics and even outright code interoperability [1] (at least for simple cases). Made it easy to remap my Sugar-centric mental model to Phoenix and comprehend "oh, okay, so that's how that works" or "so that's why I need to do this or that".

One of these days I should probably make a concerted effort to document the similarities/differences between Sugar and Phoenix and describe/demonstrate how one can at least mentally migrate between the two, both for selfish reasons (i.e. convince Phoenix users to try Sugar) and for more community-holistic reasons (i.e. position Sugar as a "gateway drug" to Phoenix).

----

[1] https://sugar-framework.github.io/docs/tips-and-tricks/ § "Phoenix Compatibility"

sansnomme• 7 years ago

Meanwhile it still doesn't have Authn/Authz built-in.

Ndymium• 7 years ago

It's a deliberate decision to not impose any set authn/authz structure on the user as many projects have differing requirements in that area.

Maybe someone could make a project creator on top of Phoenix that adds some basic authn/authz to the default structure.

Minimum Viable Phoenix

Related Stories