Discussion: Don't add a database layer to your Phoenix application

Phoenix 1.3 doesn’t “tightly” integrate Ecto into it. Even with 1.2, I don’ t think it is really a big difference.

I generally agree with @pragdave, but in this case perhaps I’m a bit more … pragmatic

People are going to visit Phoenix with a background in other “full stack” frameworks and expect some sort of a generator that gets them boilerplate code from html templates all the way to a database table. If Phoenix does not offer that, whining would occur. From an adoption and “quick wow factor” approach, having Ecto in there is a win.

On the other hand, I completely agree that in the long run, the code will be better designed if you keep web access separate from core business logic. However, that opinion comes from experience, and those with less or different experience won’t want anyone else to tell them how they have to do it. I also imagine some projects with simple requirements and/or short lifetimes really are better off with a “full stack” approach, though I’ve never in 20 years actually worked on one.

If we took even the option of using Ecto out of Phoenix, then someone would create a new hex package that wrapped them both together to offer that end-to-end out-of-the-box experience and we’ve just pushed the concern to another place.

I certainly agree with you Greg (and don’t think or am suggesting that Ecto should be removed from Phoenix). Like you said it’s currently the most common approach in the industry and so Phoenix probably needs to continue catering to that for the foreseeable future. Plus I imagine there are other benefits, such as for prototyping; when you need to get things done fast.

But it’s the other cases I’m interested in - the somewhat larger applications where this kind of approach might make sense and how common Dave’s approach actually is (I think he said that he’s in the minority in this (and some of his other approaches) at the moment).

I should also add that I’m really excited by this (and a few other things he’s mentioned) as they go back to the burning question I had when developing in another language, where I often thought that “surely there is a better way of doing things”. I know Elixir doesn’t hold exclusivity on these things, but I find it very heartening that it’s introduced to us (and perhaps so many of us) as a lot of the Elixir learning material also covers these ‘modern’ practices

I’d venture to guess he’s in the majority among people with 20+ years experience writing software professionally. But also in the minority among those with <10 years experience. And because our industry skews young, he’s in the minority overall. I hate to turn this into a point about age/experience, but I am heartened that the BEAM community in general recognizes and respects experience. Dave has been someone I look up to since I first met him 17 years ago.

I think you might like the next discussion I post then (where he thinks he’s the only person in Elixir doing it his way ) but I’m holding off for now as it’s not quite as simple as this one and I would need his permission first (to post it in the way I want to anyway).

Again I’m in complete agreement with you. In fact one of the reasons I was attracted to Elixir and Phoenix is because I felt they push us towards a better way of doing things. As much as I like Rails, and loved how easy it was to get started in, I think I’m at that stage where I don’t want short-cuts or instant gratification, but the most sensible approaches that will lead to more resilient software. So I’m definitely interested in hearing what experienced people like you and Dave have got to say

My concern is not that ecto is available in Phoenix. It’s rather that first 1.2 and the 1.3 actually tightened the coupling between the two. as a result, people will come into Elixir and assume that they should write monolithic applications. If instead phoenix.new generated a separate parallel database access application, alongside the phoenix app, then people would have the same capabilities but without the temptation to write “yet another Rails app”.

Sure, we can let people discover this over time. But if we do that, and if people start running into the same problems with Phoenix that drove them away from Rails, what have we gained? People will just move on to the next big thing.

Instead, if we explain decent coding principles, and live by them, then we can help people have a better long-term experience. This will be good for them, and good for the language.

Dave

This is what excites me most about the Elixir community. It’s not long yet, but there is a history in the Elixir community. At one point Phoenix appeared to be Rails++ and some of us encouraged @chrismccord to aim higher due to what the BEAM offers. I’m sure that was hard for him to hear at first, but the new contexts in Phoenix 1.3 demonstrates his agreement with the underlying design concerns. Even if Ecto is in the same BEAM application as your Phoenix web code, good discipline can keep them decoupled. Decoupling is the core concern @pragdave speaks of. Yes, it is easier to use BEAM applications to enforce that decoupling, and that’s my preference, but I won’t automatically judge some project that has Phoenix and Ecto in one app.

Perhaps that is self-serving because I currently work with some Phoenix 1.2 code that has them in one app. There’s plenty we could and should do to decouple them, but business needs have to be balanced with technical needs. But there’s still a decoupling mindset amongst the team that helps us to incrementally improve the code. And that ties back into your point about writing maintainable and resilient software – keep your concerns separate.

So, it’s primarily the generators that concern you?

Personally, I don’t use much beyond creating a new project and generating a new migration. I tend to code anything else generators can generate myself, by hand. I know there’s a separate audience that rely heavily on generators, but I’m still trying to understand that group. It’d be interesting to hear from them in this thread.

I think this is a fantastic idea

I don’t think the extra initial ‘complexity’ will deter people either, on the contrary I think it will do wonders in attracting even more people because as both Greg and I have commented, people are coming to Elixir and Phoenix because we want a better way of doing things.

Btw, so far everything you have said in your course like this (microservices, single responsibility functions/modules etc) makes SO much sense to me - so much so that I am actually bursting with excitement and dying for everyone else to do your course and learn these amazing things as well!! THANK YOU DAVE <3

Yep, and the same with Ecto when that had a change in direction. I think it shows remarkable strength and I feel it’s been incredibly good for Elixir - because people are taking note that the developers aren’t afraid to make changes if it means resulting in a markedly better product