
Minimum Viable Phoenix - pcorey
http://www.petecorey.com/blog/2019/05/20/minimum-viable-phoenix/
======
yellowapple
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
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](https://hexdocs.pm/phoenix/up_and_running.html)

2:
[https://docs.djangoproject.com/en/2.2/contents/](https://docs.djangoproject.com/en/2.2/contents/)

3: [https://pragprog.com/book/phoenix14/programming-
phoenix-1-4](https://pragprog.com/book/phoenix14/programming-phoenix-1-4)

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

------
dve
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
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](https://github.com/pcorey/minimum_viable_phoenix)

mix deps.get

mix compile

mix phx.server

and you're good to go

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

------
xtagon
I really like this style of "literate commits".

------
gojomo
What is Phoenix?

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

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

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

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

------
seeker61
Another framework. May merciful Providence deliver us.

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

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

~~~
eropple
React is nigh-universally agreed to solve a set of problems related to
frontend web development. You may not recognize the pain of those problems and
it may not solve them the way _you like it_ , but the way you've attacked the
sentence is really strange.

~~~
nickjj
What if you could eliminate a lot of the pain points that React solves but
without having to write much (if any) Javascript but still have an application
that feels like it's rendered client side while getting server side rendered
templates for free, and things like "but I can share my logic between the
backend and frontend" goes away because the backend can do both?

This is just one type of problem that Phoenix's LiveView solves and LiveView
is only a small aspect of what Phoenix has available. I'm very thankful work
is being done in this area instead of just accepting that everyone wants to
use React.

~~~
eropple
I mean, cool, great. I like React and I like TypeScript more than I like
Elixir so that does nothing for me, but great.

But I'm not sure why you replied to me.

