https://github.com/phoenixframework/phoenix/commit/c3351478748779fe0b777a4f41e7ace7ae5e2452
michalmuskala
9
astery
I love Rails, and for me, it never was about:
I love Rails, because of it awesome guides! For me as an inexperienced developer, Rails taught me how to do beautiful things, how to work with MVC and AR. I like rails because as an inexperienced developer, I can just follow the guides, and be sure that I use best practices.
In Rails, no one forces me to place views in a separate file, I can just put a bunch of text in a controller. No one forces, to use separate actions, for a separate route, I can just use one action for every route I have. No one forces me to use rest conventions.
But following guides, I see how my code become clearer to understand.
Phoenix generator, just as Rails generators, a bootstrap for start, or a learning example. No one has to follow to an idea of separation domain logic from web-framework, but we should provide good examples, that can give insight to novices, or can be usable for experienced users.
5
Crowdhailer
Creator of Raxx
I think that is a very reasonable middle path.
I have spent a lot of time thinking about bounded contexts, in elixir and other languages. It is often difficult to work out exactly what they will be up front. When start a new project I often have two namespaces. one called www (not web because most services are likely to be available over the web) and one called operations. Projects then evolve often gaining an admin and/or analytics context. After that stage is when the ‘operations’ context starts breaking down into useful services and perhaps vanishing all together.
3
AlexMcConnell
And the reason Rails has awesome guides is because of all the people who found it, fell it love with it, and made those guides awesome before you came along.
0
AlexMcConnell
Using a generator forces you to use them, and generators exist for the express purpose of making it easier on newer developers.
2
AlexMcConnell
The fact that they need to focus on learning all of those things is exactly why more shouldn’t be added to it, although I doubt that many, if any, people are finding Phoenix currently that are completely unfamiliar with html, css, and javascript. And it’s not really about them struggling with it, it’s about the fact that they simply aren’t going to want to learn that before they learn to do “cool things.” The expectation for proper organization and use of modules is fine for people who have already committed to using Phoenix. Selling new people requires letting them see what they can do with minimal effort.
1
sztosz
Still, no one forces you to use them. And when learning new framework yo’re better off without them anyyway, because instead of answering some questions they just raise more.
I think that Phoenix is not aimed at people that want to do just “cool things”. Phoenix and Elixir is rather aimed at people who understand terms like distributed and fault-tolerant. And to know them, and understand value of distributed and fault tolerant software, you really have to do some real world programming. And if you done that, you know you don’t want sot that’s cool, but rather software that is easy to maintain.
I really, really don’t understand why there is a need for phoenix to give up teaching good practices just because some people can’t or don’t wan’t to spend some time (very little actually) to understand where does those practices come from, and why they may be important.
4
sasajuric
Author of Elixir In Action
About a year ago, my team started working on a Phoenix app. We all had experience with Erlang, building web servers, and software development in general. None of us had experience with Phoenix, though, so we followed patterns encouraged by the official docs, generators, and other independent blogs. We started with Phoenix 1.1, so there were no context, and there were still models. We moved quickly, and produced a lot of code in the next few months. Unfortunately, that lead us to a quite interleaved code with unclear boundaries and responsibilities. It became increasingly harder to maintain and extend such code. Some six months after we started, we agreed to clean up our controllers, and move other concerns to “service” modules (which I feel resemble the official contexts being introduced with 1.3). To this date, our code is still not completely there.
My takeaways from this experience are:
- Framework plays an important role in determining the code organization. Even as experienced devs, we simply stuck to defaults promoted by Phoenix at the time.
- It’s much harder to refactor the code post-fact. Having worked on some terrible legacy (and sadly produced some of my own), I strongly feel that your only chance of keeping the control of your code is to pay attention to it from the very start.
- Keeping the Phoenix part of the code (controllers, sockets) focused only on HTTP related tasks, basically making it just the interface to the rest of the system is a very good way to structure any production app.
Therefore, there’s no doubt for me that contexts are a very good idea which will push developers in good direction, promoting better code organization patterns. I agree that this will make things slightly more confusing for newcomers, because it’ another idea they have to grasp. However, I think that this is a good trade-off. A bit of approachability is sacrificed to get much better code organization.
I’m somewhat worried about this mantra myself. I have a feeling that for some people it means “Phoenix is not your OTP application”, and that we should always organize our system as umbrella apps. I definitely don’t share that view. For me, the core idea here is that Phoenix is an http/ws interface to your system. You take the input, validate it, and then invoke some other part of your system (i.e. some function from some module in some other namespace), and finally convert the result of that function into desired output (html, json, …). That’s a clear separation of responsibilities, and can lead to much more readable code. And a readable code is a win for everyone, especially for newcomers.
22
brightball
I think the bridge between his comment and yours is that newer developers shouldn’t be the ones getting paid to architect a new environment for a company’s systems. If they are then they more than likely had a choice in deciding what language to use and if they chose Elixir and Phoenix, you would assume it’s because they knew it already and not that their employer let them pick something and then spend a while learning it.
If a more senior developer chose it then your concerns are largely laid to rest and you get the benefits of a more modular environment for future new hires to come into.
I have rarely seen much beyond “I need a website” type work entrusted entirely to new developers. If somebody with an actual development budget did that for a business application, it would be a shock.
1
sztosz
About Phoenix is not your application. For me it means Phoenix is not your whole application. Don’t think of your logic being part of Phoenix application, but rather other way round. Phoenix is just a part of your application, call it a frontend, or UI, or whatever. But write your app in such a way, that it can live on it’s own without a phoenix, so that you can add a CLI for it easily or desktop GUI, or another interface for communication, like system bus, or other than HTTP network protocols. Because you newer now if you’ll need that and writing it like this does not cost anything, beside more thinking how to structure your interfaces well.
6