9 ms·

Minimum Viable Phoenix

174 points by pcorey 7y ago

seeker61 7y ago
Another framework. May merciful Providence deliver us.
- fouc 7y ago
  Hmm? You haven't heard of Phoenix/Elixir? It's mentioned on HN fairly often.
  - ncmncm 7y 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 7y 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.
  - theonething 7y 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.
    - nicolas_siplis 7y ago
      Whether or not you like React, the point is that it's solving a problem. Maybe not for you, but (I'd like to believe) at the very least for some of your colleagues.
      - theonething 7y ago
        True that whether I like it or not doesn't matter in a business and team sense. I should have phrased my comment better. I don't believe it is solving a problem. It's creating unnecessary complexity. The app is just a typical CRUD app. Traditional server side rendering would be fine in my opinion. Or perhaps coupled with LiveView or TurboLinks, and Stimulus.js. Btw, this is not so much a knock on React specifically, but on the overuse of the SPA paradigm [1] So in conclusion, using React in this case (in my opinion) doesn't solve a problem and yet I need to use it. [1] https://news.ycombinator.com/item?id=19134260 https://news.ycombinator.com/item?id=19134260, https://news.ycombinator.com/item?id=19184496 https://news.ycombinator.com/item?id=19184496, https://news.ycombinator.com/item?id=19905004 https://news.ycombinator.com/item?id=19905004
    - colonelpopcorn 7y ago
      Ostensibly, because it helps to solve the problems you've been hired to solve...
    - eropple 7y ago
      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 7y ago
        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.
- ramchip 7y ago
  It’s the only framework with significant usage in Elixir. I don’t think one framework per language is excessive.
deleted 7y ago
[deleted]
gojomo 7y ago
What is Phoenix?
- eldenbishop 7y ago
  Given there is an active Apache project called Phoenix (https://phoenix.apache.org https://phoenix.apache.org) I think confusion here is warranted.
- brightball 7y 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 7y 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 7y ago
I really like this style of "literate commits".
drcongo 7y ago
This is a really great idea and well executed. Thank you.
dve 7y 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 7y 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 https://github.com/pcorey/minimum_viable_phoenix mix deps.get mix compile mix phx.server and you're good to go
  - dve 7y 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.
yellowapple 7y 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 7y 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 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
sansnomme 7y ago
Meanwhile it still doesn't have Authn/Authz built-in.
- Ndymium 7y 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.

174 points by pcorey 7y ago

seeker61 7y ago

Another framework. May merciful Providence deliver us.

fouc 7y ago
Hmm? You haven't heard of Phoenix/Elixir? It's mentioned on HN fairly often.
- ncmncm 7y 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 7y 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.
- theonething 7y 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.
  - nicolas_siplis 7y ago
    Whether or not you like React, the point is that it's solving a problem. Maybe not for you, but (I'd like to believe) at the very least for some of your colleagues.
    - theonething 7y ago
      True that whether I like it or not doesn't matter in a business and team sense. I should have phrased my comment better. I don't believe it is solving a problem. It's creating unnecessary complexity. The app is just a typical CRUD app. Traditional server side rendering would be fine in my opinion. Or perhaps coupled with LiveView or TurboLinks, and Stimulus.js. Btw, this is not so much a knock on React specifically, but on the overuse of the SPA paradigm [1] So in conclusion, using React in this case (in my opinion) doesn't solve a problem and yet I need to use it. [1] https://news.ycombinator.com/item?id=19134260 https://news.ycombinator.com/item?id=19134260, https://news.ycombinator.com/item?id=19184496 https://news.ycombinator.com/item?id=19184496, https://news.ycombinator.com/item?id=19905004 https://news.ycombinator.com/item?id=19905004
  - colonelpopcorn 7y ago
    Ostensibly, because it helps to solve the problems you've been hired to solve...
  - eropple 7y ago
    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 7y ago
      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.
ramchip 7y ago
It’s the only framework with significant usage in Elixir. I don’t think one framework per language is excessive.

deleted 7y ago

[deleted]

gojomo 7y ago

What is Phoenix?

eldenbishop 7y ago
Given there is an active Apache project called Phoenix (https://phoenix.apache.org https://phoenix.apache.org) I think confusion here is warranted.
brightball 7y 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 7y 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 7y ago

I really like this style of "literate commits".

drcongo 7y ago

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

dve 7y 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 7y 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 https://github.com/pcorey/minimum_viable_phoenix mix deps.get mix compile mix phx.server and you're good to go
- dve 7y 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.

yellowapple 7y 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 7y 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 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

sansnomme 7y ago

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

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