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

It is important to say that nobody is advocating to “put everything in the same app, forever”. To me a great sign for splitting your Phoenix projects apart is exactly when you need to communicate to extra data sources, be it batch processing from CSV files or an API from a third party vendor.

Some have mentioned microservices in this conversation but what is being proposed, which is to split into multiple applications that depend on the same database, is against one of the core tenets of microservices/SOA which is operational isolation.

I understand some may still prefer to build their projects with multiple applications talking to the same database because it gives them more isolation at the application design level. But I also understand those who prefer to split things apart when you can actually guarantee they are fully decoupled. YMMV.

The only thing I am 100% sure is that if Phoenix generated multiple applications by default, we would be discussing how it is a terrible choice for most applications, how it is verbose, how it gives a false sense of security due to the operational coupling and how it is in general over-engineering. I am not saying I agree with any of those, just pointing out those discussions will happen regardless of choice.

That’s why I am glad we were able to grow Phoenix+Ecto to the point were all of those choices are possible. I like to say languages, frameworks and libraries should “enable rather than provide”. Languages more than frameworks, frameworks more than libraries.

And while we need to pick one approach for generators, the fact Phoenix just calls modules from the web layer, allows you to put your business logic anywhere: in the same app or different ones. And in there you can even get rid of the database altogether. It doesn’t care.

It’s possible that we are overthinking this and if I’ve got to choose between one of these approaches, I think Phoenix is getting it right by encouraging and enabling separation rather than forcing it.

Completely separate applications come with a lot of hidden complexity that doesn’t generally need to be introduced until you really require it. The whole microservice vs monolith discussion generally boils down to isolation of dependency trees and resource consumption at its root. If a monolith is built with an object oriented language, you end up with this horrifying blur of inheritance chaining that’s incredibly messy to untangle. If you go microservices from the start it’s good long term but you pay for it up front with potentially unwarranted complexity.

With the approach from Phoenix and Umbrellas you don’t have a tangled mess, thanks to the way Elixir is designed. You’ve got smaller parts in their own zones that are significantly easier to separate when you finally NEED to.

Learning curve and on-boarding are a huge deal for a language. Determining trade-offs that get people moving quickly in the right direction is a key and it’s one of those things that is hard because you’re always sacrificing something. It’s something programmers debate about constantly because business factors like turnover, training, learning curve and time to market are real factors that matter beyond ideal architecture. Ideal architecture seems a lot easier when those other factors aren’t included IMO.

In that regard and from a community standpoint, I really do think that Phoenix 1.3 has nailed that balance. Like anything else in programming, it’s always a question of trade-offs and hidden costs.

If we aim for architectural purity instead of that balance, we aren’t going to be much better off than the “OMG Benchmarks!” crowd. If productivity, learning curve, training time, etc aren’t a factor then why aren’t we just using Erlang?