Contexts are literally well named modules and functions, and we ask you to think about the API boundaries are you are building your well-named modules an functions. That’s it. If you think that’s a bad idea, then you are saying the way we all build functional programs is a bad idea

When you build a phoenix project, it literally is an “OTP application”. This conflation w/ the above tweet ignores a lot of details about the elixir and ruby worlds. In Rails, your project is a special directory structure tailored to a Rails application. The entire program is started and stopped according to special rails init code. Contrast that with the way we build Elixir applications, they are all OTP applications, with standard start/stop mechanisms and explicit application relationships. “Phoenix is not your application” absolutely applies here and pushes folks to think differently about Elixir as a platform, since it’s unlike what they’ve been exposed to before.

Baby-steps! This is exactly what mix phx.new my_app --umbrella does. [quote=“sync08, post:15, topic:4367”]
If I am wrong then please tell me. I realize that I sound very negative but I assure you that I’m very open to ideas.
[/quote]

You are wrong . Thanks for the feedback!

One more comment on this.

First of all, Elixir is not Ruby and Phoenix is not Rails. Ruby, opposite to Elixir, does not provide any mechanism for structuring your projects. Most of the standards you see today in Ruby came from the community.

In Elixir, we do have such structure. Elixir itself has the concept of applications and how code is structured. Those are pushed as part of the language and its tooling.

When we say Phoenix is not your application, it is not some anti-Rails instance. So don’t make it so. It is literally how writing projects work in Elixir (and Erlang/OTP). We had technical reasons for generating the “web” directory in previous versions but those have been solved, so Phoenix projects should follow the standards in the community instead of fragmenting it.

The way we are advocating Phoenix applications to be structured is exactly how community projects such as Elixir itself, Phoenix and Ecto are structured. In Ecto, we have “contexts”, such as Ecto.Repo, with private modules inside, such as Ecto.Repo.Supervisor. Only Ecto.Repo is allowed to talk to Ecto.Repo.Supervisor. Sometimes we do violate this rule by making an inner module public but that’s exactly the point: building a project with Phoenix should be no different from building any other Elixir app.

The more I read about contexts the more I think it’s a bad idea.There seems to be a big push for “Phoenix is not your application” which, as far as I can tell, is nonsense. It’s a very big anti-rails movement.

Phoenix is your application. It’s a framework that serves as the foundation which you build on top of.

Ecto, Plug e.t.c. are libraries which are not your application. You use them as libraries and as such they don’t impose any structure. You’re free to do use them as you please.

A relevant quote from dhh.

https://twitter.com/dhh/status/218740829806792704

It doesn’t help that the two main people behind Phoenix and these changes propose this complex new structure and both reply with the same “oh no we can’t give examples because it all depends on what you’re building.” I don’t mean to sound too critical but this screams change for the sake of changing.

What we have now is a situation where we have multiple isolated contexts in the same app but are discouraged from actually using them as a whole. e.g. we shouldn’t have relationships to other contexts in schemas. This is pretty backwards because if you have these in the same app you are certainly going to want to use everything together.

I personally don’t think that contexts is the right solution. I also don’t think we actually had a problem in the first place. If you really need separate isolated contexts then they don’t even belong in the same app.

Contexts as they are now are a bastardization of DDD and the repository pattern.

Umbrella apps are where the attention should have been focused. Fully separate apps where necessary and a web app that ties them all together.

If I am wrong then please tell me. I realize that I sound very negative but I assure you that I’m very open to ideas.