What do they actually mean when they say "Phoenix is not your application"?

Phoenix Forum Questions / Help
1

I hear this sentence from almost every teacher, teaching Elixir and/or Phoenix. What does it actually mean?

2 Likes
2

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 :slight_smile:

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

4 Likes
3

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

Topics:

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

12 Likes
4

My name is Lance Halvorsen and I endorse this message. :+1: :grinning:

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.

8 Likes