The push for contexts encourages folks to use discrete APIs exactly to decouple the two.
To a point. But the code still lives in the Phoenix app, so the presence of contexts actually encourages the exact behavior that is long-term harmful.
It seems to me that contexts are simply a way of creating service apis.
If I were writing an application that had services, but I included those services in one of the endpoint API modules, that would generally be considered to be a bad design. Why, for example, would a user creation service be part of my web API module when I would also use it from my command line and from my batch processing?
So I really think that offering contexts as part of Phoenix is wrong. It says that the Elixir community supports this kind of coupling.
But the reality is that the Elixir ecosystem is one of the few that actually supports the proper (and efficient) splitting of these responsibilities.
I really don’t buy the “ease-of-entry based on new user expectations” argument. If I did, I’d write a PHP interpreter as part of Phoenix. Instead, I think we make the entry easier by making it simpler. Give people a good architecture, where everything has it’s place, and where decoupling is the norm. The aim isn’t to write a 10 minute blog—it’s to write a five year application.
Parallel (not umbrella) applications are trivial to create and manage, and have decoupling built in from the start.
Except… this assumes that the Calendar context/service is part of the Phoenix app (assuming MyApp is one), and this just doesn’t make sense. Phoenix is not the application. It’s a way of accessing the application.
Dave
