I wasn’t talking about the generators. Rails is magic.
AlexMcConnell
hubertlepicki
To be fair, I don’t have much love for Phoenix approach to “contexts”. Personally I do not see this as something I will use, and I actually agree that I will not recommend this to be used by newbies either.
I do think that Elixir/Erlang/Phoenix already comes with better alternative in form of umbrella application / Elixir/Erlang applications. And, truth to be told, Phoenix 1.3 does improve support for umbrella applications in form of new generators phoenix.new.web or phoenix.new.ecto.
I currently use approach of having umbrella app containing of several applications: “base” or “core” where say Ecto is used, “web” or “user_interface” where user-facing UI sits, “admin_interface” or “backend” for UI to perform administrative tasks etc. It is already easy and convenient to create such applications, and they do have additional advantage over contexts that they can be easier built, deployed, restarted as units.
Contexts seem like a way to improve the code structure of application where you put everything into “web” application. Which is not something I want to do in first place 
AstonJ
//
Some posts regarding the OP’s intentions have been removed - generally we tend to give people the benefit of the doubt - but if you feel someone is a ‘bad actor’, please flag their post for a moderator to take a look (rather than tackle them yourselves) - this helps the thread from getting derailed. Thanks 
//
wmnnd
I also quite like to use umbrella applications instead.
But then again, for newbies just starting out with Elixir, that might actually be a little bit too much.
@josevalim, @chrismccord: Why did you decide to go with Contexts rather than umbrella applications by default? Was it the concern that going all-OTP right away might overwhelm new users?
Qqwy
TypeCheck Core Team
To speak from my own experience, I frequently have multiple contexts that I want to be part of the same OTP supervision tree.
I have started Phoenix projects with as umbrella project in the past, and I think that for most projects it does not make a lot of sense to do this when starting out. Umbrellas add an extra layer of complexity (because of the separate OTP applications) that contexts do not have.
But this is definitely an interesting question, as I hadn’t consciously thought of why I did one or the other before! 
jeremyjh
You should really watch the introductory talk by Chris - he explains you should really only consider separate OTP applications when the applications have independent storage. Contexts are intended to allow more cohesion / coupling than you’d want in those cases.
Speaking for myself I’m glad to see Contexts in the generators. I had found myself creating something similar on my own; I was a little dismayed when I first looked into Phoenix and saw all the database work done directly in a controller. Having it in the generator saves me a little work upfront.
josevalim
Creator of Elixir
That’s not quite true. You can use the Phoenix --umbrella flag and have two apps: one for web and one for your domain. So you can have all of your contexts in an app with no “web” parts.
Also note that, if all applications depend on the same data source, such as “base” or “core”, they cannot be deployed in isolation. Imagine you have new migrations and you deploy a new admin which requires those new migrations. Once the migrations run, you may break the “web interface”, which is not using the new data. So in this case umbrellas may segregate the code, but the operation is still coupled.
In any case, umbrellas definitely have their place and if you are comfortable with them, then surely go ahead. But remember they are somewhat orthogonal to contexts (which again, is just organizing code in modules) and definitely require more discipline.
josevalim
Creator of Elixir
To me different business applications in the same umbrella should have data isolation, otherwise they are still coupled at the operations level (see my previous comment). From that, it is easy to see that it would be overly complex if mix phx.gen.html generated a new app with its own database in an umbrella every time the generator is run with a new context argument.
Also, remember those concerns are quite orthogonal. Contexts are modules. And all applications will have multiple modules. If you want to use umbrellas, then I would have an app with all of your contexts and another for the web interface, which is exactly what the --umbrella flag does.
hubertlepicki
Of course they are still coupled, and of course in many cases you will deploy them at the same time. It’s nice to have functionality, however, to re-design a registration page as new umbrella app, deploy it to running system, feature toggle it or A/B test and get rid of it if works worse than previous one. It’s the stuff like this that makes this umbrealla-based architecture extremely appealing to me.
When it comes to contexts, it all seem to boil down to generators and what is namespaced in the context module and what not. I think good software developer would namespace their code in similar manner anyway. However, I do not see the reason to namespace modules that I consider part of application infrastructure and those are for me:
-
Controllers, views and templates. I’m fine if these are flat layered under “Web” or whatever. It’s just the glue that takes parameters, forwards request to services layers and renders response.
-
Database-mapped Ecto modules. I generally namespace it under “Db” or “QueryDb”, “WriteDb” etc. This is also just the glue that allows one to read and write data to database.
In this approach you have clear focus on what is core of your application and what not. UI is important but it’s not your business logic. Database is important but it’s not your application either.
I do not think that one should treat “Comment” as a database-mapped struct namespaced in context “BlogPosts”, because it’s external data, stored in table “comments”, in some external database “Db”. If we really kept that data internally, private to context - then yeah, it makes sense. But we don’t do that, most likely.
The reason for 1) not making sense for me is that UI will most likely diverge from and cross the boundaries of contexts anyway. The reason for 2) is actually the same, if you have single database, the queries to this database will cross contexts anyway.
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
It’s about the organization of business logic, and it’s a lot more about writes than reads. Consider the system we have at Cargosense. We track shipments of goods, with sensors on those goods to monitor environment data.
Our app started pre Phoenix 1.0, and so we naturally have a models directory with quite a lot of modules. Some of these could possibly be broken into an umbrella but even with that, our core application really does require quite a few tables.
Core shipment operations (start, stop, etc) need to touch a variety of tables that constitute what a shipment is (shipments, environments, containers, sensor_installations). Right now there isn’t a good place for that logic to sit. It doesn’t belong in a controller, and it doesn’t belong in any one schema module.
What I have right now is a set of use case modules, and the code sits in one of these. The issue is that the structure of the application code doesn’t really offer any clue that shipments, environments, containers, sensor_installations are part of some logical unit that should be generally manipulated via the business logic in my use case module.
Reorganizing my existing models directory into a pod structure under contexts makes it clear where the default location is for the business logic that is responsible for the underlying tables lives.
Reading data from multiple contexts isn’t really a big deal. I’m in the middle of finishing some GraphQL helpers that will make this particularly easy even without the associations.
To your points directly:
- UI will most likely diverge from and cross the boundaries of contexts anyway.
Of course! But you don’t organize your contexts on the basis of UI concerns. Pulling data from multiple contexts is completely fine. If you’re using something like GraphQL then it’s even clearer that you have internal organization, an external representation and then a mapping to go from one to the other.
if you have single database, the queries to this database will cross contexts anyway.
This is no longer considered problematic.