I’ve been thinking about this a lot lately and I worry that we are raising the barrier to entry with talk like that. I’ve seen ElixirConf talks and DailyDrip videos that put the emphasis there. While I agree with the long term architecture pattern of looking at Phoenix as just the web interface to your application, OTP and BEAM are very large and take a while to fully wrap your head around. It can leave you with the feeling that by building a fully functional app within Phoenix as you would in any other language that you are somehow doing it “wrong”.
In a functional language where you don’t have to worry about nested object dependencies all over the place it seems like separating out the parts later on to break “your application” out of Phoenix should be very straightforward, which is kind’ve one of the perks of Elixir in general. Would we be better off pushing, “Phoenix is absolutely your application…for now” to avoid the intimidation factor of getting into all of these new concepts for many developers?
Honestly I’d just call Phoenix the web server (technically cowboy is, but phoenix is a very nice interface on it and others do not need to work with cowboy directly) and pubsub server, what should be pushed would be ‘Elixir’ to me.
I do not believe there is any difference between functional languages and object oriented languages in that matter. The tight coupling between elements of your framework/ui and your application will bite you in the, well, as much as in Rails
Does “as you would in any other language” actually mean “as you would in Rails” or “as you would in any framework”. There are some circumstances were excessive decoupling/separation counts as “over engineering” that simply (over)burdens the development process. In other circumstances approaching a problem in an overly simplistic manner results in complex and brittle solution. It is always a delicate balancing act. For example as Eric Evans points out in his Smart UI Anti Pattern, “Smart UI” can be appropriate in some situations were “DDD” is counterproductive but conversely “Smart UI” will lead to disaster when “DDD” is necessary.
I think it is important to explicitly monitor and manage technical debt with the commitment to refactor once it becomes evident that the “easy way” is going to lead to an overly complex and brittle solution. Hopefully by then more information will be available to indicate where decoupling will yield the most benefit. On the flip side it is just as important to be able to explicitly justify any decoupling overhead that is accepted up front in order to not burden the development effort with any unnecessary overhead.
So you could almost say that “doing it right” is an unattainable ideal but yet every day we have to try to max out our doing it mostly right gauge.
In reference to Phoenix the good news that Phoenix doesn’t have to be your application if you don’t want to - the same couldn’t be said for example of Rails.
In software development pandering to beginners can backfire and in my opinion has contributed to the emergence of the Expert Beginner. The other issue is that the “easy way” always leads to a solution that has a blueprint/footprint of a web application rather than that of the domain solution. In essence the fact that the solution is deployed on web servers to deliver a browser UI completely overwhelms any domain concerns. The “Phoenix is not your application” approach separates the core domain solution from the interaction component as supported by Phoenix (see also Robert C. Martin: Architecture the Lost Years (Ruby Midwest 2011)).
My two cents would be saying phoenix is not your application is definitely the right thing.
Sometimes you get told something like this which as a beginner you don’t fully get. To my mind thats what being a beginner is about. I wish I had been told this earlier on when I was learning rails and I would probably still have written some tightly couped code.
Presenting alternative advice for people who are not ready in my opinion is rarely helpful
This is the way I look at it: learning Elixir (and Phoenix) is like learning a new human language and culture — like moving to another country. Assuming everything works the same as in your old country/culture is potentially embarrassing or even dangerous. Someone from the US should not assume one drives on the right side of the road in their new country. They should not assume how much to tip at a restaurant. They should not assume a level of punctuality they’re familiar with.
I want beginners to be welcome and productive, but I also want them to question their assumptions.
As a teacher, I don’t find it helpful to tell people what things aren’t, I find it it better to explain what things are. In my experience, only people who have the full context can really understand negative logic. I explain it as “Phoenix is the web-based UI for your app.” This has been especially important to explain to people from Rails who are trained not to put anything outside of the fat models and chubby controllers.
That is the best point against the mantra I have heard! You are correct, that the negative statement makes most sense to those with a Rails (and perhaps others too) context. I hadn’t considered that before. I nod completely at “Phoenix is the web-based UI for your app” but perhaps we could brainstorm other ideas too. I’d love to find something a bit more slogan-ish and catchy.
Phoenix is the atrium of your building
Phoenix is the cockpit of your jet plane
Phoenix is the cover of your novel
Phoenix is the icing on your cake
Phoenix is the lead singer of your rock band
That’s how I like to think about HTTP part as well. I just call it interface to the system to avoid confusion that HTML is in fact about UI, but e.g. REST requests aren’t, although they’re still interface to the system.
If I recall correctly, this topic (e.g., umbrella applications) was going to be addressed in an update to the Programming Phoenix book (1.3 update?). If that is the case, it makes grokking this concept easier for readers and beginners, alike.
Already covered in programming-phoenix_p1_0 p.231 “Chapter 12: Using Umbrellas”. That being said the reader is introduced to Phoenix in a “Phoenix is your application” kind of way until about p.199 “Chapter 11. OTP” - in its defense the book is primarily about Phoenix as such - building distributed web applications with Elixir could potentially have a much more expansive scope.
Yes, you’re right. ( I’ve also read the book ) To clarify, I was referring to an emphasis on the rumbrella app architecture in the Programming Phoenix 1.3 book than the 1.2 version since the latter focused mainly on the Rumble app architecture, and I think the Rumbrella architecture would be the right approach (with exceptions) for large and/or disparate enough apps.
BFF - Backend For Frontends rather than Best Friend Forever because we really don’t want them to share their secrets (i.e. become tightly coupled) even though the Phoenix part is supposed to be extremely supportive by dealing with pesky front end traffic and concerns so that the application can do what it does best - conduct domain logic.
I know, I know…
It doesn’t work if you have to explain it.
It doesn’t do justice to the front end support in Phoenix (templating, JS libraries for channels, etc.) and isn’t all that accurate (though this wouldn’t be the first time in the industry that a moniker has been re-purposed).
The source https://github.com/wojtekmach/acme_bank is a great example of an umbrella app. For example, he uses two instances of phoenix (backoffice and bank_web). It’s a working app, so you can experiment with it too.
That’s how I like to think about HTTP part as well. I just call it interface to the system to avoid confusion that HTML is in fact about UI, but e.g. REST requests aren’t, although they’re still interface to the system.
