Fl4m3Ph03n1x
Do we need Phoenix at all?
Yes, the title is triggering you. I know ![]()
Other dissenting (or perhaps a better word is “skeptical”) views have been less formal. One person simply asked me: “Have you ever actually done this – in a Phoenix project ”, as if Phoenix was somehow special and changed the game so much that the normal rules of good design don’t apply.
If you recognize this quote from the days of old, then you know there is something strange about it… Perhaps a word or two that may have changed slightly ![]()
This post is a reflection on an article from Uncle Bob.
He defends our architectures should focus on 3 things:
- Boundaries(deal with the outside horrible world)
- Entities (business logic)
- Interactors (pass information between 1 and 2)
Now, this would make your Application logic. But you may be thinking: “Your app seems to suffer from a distinct lack of … everything else”.
Indeed I don’t mention databses, UIs, web controllers, sockets … nothing. According to the article, these are just annoying details - frameworks are annoying details, Phoenix is an annoying detail.
The article defends that you know you have a good architecture when the framework you use in your app can just be like any other plug in, that you can add and remove and update at will.
This concept is really interesting but I have never seen in my life an application following it. So I have some questions:
- How does the Elixir community feels about this? Agree, disagree …
- Are there any examples of an app using this structure?
Trending in Discussions
Other Trending Topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance










First Post!
hauleth
Answering the question:
No
We do not need Phoenix, at all. It is just convenience library that you should treat as implementation detail, and that is what new directory structure in Phoenix 1.4 (or 1.3 I cannot remember) does - separate application from one of its interfaces.
Of course I am yet to see any project that decides one day that they do not need the framework X and replace it all with framework Y, but that is not the point, the point is that you can do it, not that it is feasible to do. If the project is tightly coupled with everything you cannot replace framework without rewriting all of the application, if there is distinct separation then you can. Think of it like “breaking” cryptographic algorithms, we have key-recovery attack on AES which is faster than brute force by factor of ~4, which mean that you need 2254.6 operations, which mean that it is possible, just infeasible.
But returning to Phoenix applications, I have written Imager which I still treat as a best piece of the software I have written so far. I can easily replace any part of it (some parts are configurable at the time of the speaking) and to be honest I have replaced some parts of it already (replaced
Porcelainwitherlexec) almost without touching any other parts of the application.TL;DR
Do we need the Phoenix? No we do not, but it is making some kinds of work much easier and simpler.
Most Liked
LostKobrakai
This is interesting as Phoenix is making a hell of an effort that you don’t couple yourself to it. Basically the whole idea behind contexts in phoenix, which was introduced in 1.3, is trying to make you not couple your application logic to the web layer (which is essentially what phoenix does). There’s no mention of phoenix anywhere in generated context files. You could remove the whole myapp_web folder and anything left would still work. Put a plain plug based web layer in front and you’ve essentially “switched frameworks”.
gregvaughn
@Fl4m3Ph03n1x , for someone so new to the community, you certainly do seem to relish clickbait-y controversies. I would suggest a more irenic approach.
Note that linked talk above was given in 2016, by @lance a longtime community member and also the author of Functional Web Development with Elixir, OTP, and Phoenix. He’s clearly spent considerable time thinking through these issues.
My own summary answer to your query is
a) no, your application does not need Phoenix, but
b) yes, The Elixir Community does need Phoenix.
lance
Thanks @gregvaughn and @easco for the shoutouts!.
I personally prefer to think of Phoenix as a tool for building web interfaces rather than web applications. I try to avoid the term “Phoenix application” as well because I think it limits how we think about our approach.
In my book, that Greg alluded to, we build a fully functional application without Phoenix. That’s the first two thirds of the book.
Only when we want to make that application available on the web do we layer on a Phoenix interface. We keep the code for those two parts physically separate by means of a poncho project, as much to help the flow of the book as anything. That’s the last third of the book.
My quick response to the question:
You can definitely build a complete application without Phoenix. (I think doing so brings some strong benefits.) If you need for it to have a web interface, though, Phoenix is a fantastic choice.
Last Post!
mikemccall
I can see how the message was lost in context. Simple is always better