The phrase was coined by Lance Halvorsen - Phoenix Is Not Your Application (ElixirConfEU 2016).

Topics:

• Phoenix is not your Application - questions
• How important is the “Phoenix is not your application” mantra?

Points

• The idea isn’t actually new - but it seems that web development (RoR in particular) needed to rediscover the concept - e.g. Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin (and it wasn’t new back then either).
• Design the application code in such a way that all its capabilities can be exposed via different user interfaces, e.g.:
• command line interface
• native desktop user interface (not something like React Native but more like Swift and not necessarily via a remote server but more like a local application).
• web ui (Phoenix + browser frontend)

i.e. decouple the application logic entirely from the nature of the UI (the “mode of delivery” for the application’s capabilities).

• Dave Thomas actually pushes the idea even further to “Your Database is not Your Application”
• Don’t start by defining your DB tables - that is just your “data-at-rest”. Make informed design decisions based on your “data-in-motion” by designing your essential data transformations (based on your problem domain) first.
• Pushed to the extreme this also means that your domain logic should be “persistence technology agnostic”.
• Ultimately this goes back to the old idea of a “Layered Architecture”.
• However this time around that “layered architecture” isn’t designed “bottom-up” (DB-first) nor “top-down” (UI-first) but “inside-out” (domain-capabilities-first). Conceptually the middle layer (domain-layer) defines all the “interfaces” that the lower layer (persistence-layer) and the upper layer (UI-layer) have to implement.
• So the lower layer has to implement the interfaces so that the middle layer can retrieve the necessary data and save and update the necessary data. The upper layer has to implement interfaces to gain access to the middle layers capabilities.

FYI: Your database is not your application - by Hubert Łępicki - Code Europe Autumn 2016

My name is Lance Halvorsen and I endorse this message.

If I could add one small bit to what @peerreynders has written here, it would be that OTP’s Application Behaviour is the thing that makes this way of working feel much more natural in Elixir/Erlang than in other ecosystems.

It means phoenix is not the main concern when You start your project. It should be business/domain logic first, and only then, wrap phoenix around.

@pragdave is advocating for this, and in his course, he starts building a game engine, then only after, he wraps it with a web interface. and shows how simple it is to change interface… like a text console interface.

In practice, that means umbrella project are strongly encouraged, as a way to separate concern.

Also, as a personal opinion, I find very nice to build simple domain modules, join them together, and only at the end, add phoenix as web interface

I think it was a Rails concern at first, where building huge monolithic application was usual.