I’m also not a fan of this term. Besides sounding quite vague, it seems to be associated with DDD a lot. At our work we use “service” but I think that’s even worse 
. “Concern” proposed by @OvermindDL1 sounds better. Or maybe just “business module”?
6 Likes
I took some time writing down my thoughts about Contexts a little in the form of a slightly longer blog post:
Lately, there has been quite some discussion about the new ‘Contexts’-feature that is going to be added to Elixir’s web framework Phoenix in version 1.3.
Some people are confused by them, some people believe ‘they are terrible’, some only believe that there needs to be a little extra information of how to use them in practice.
So, here are my two cents on how to approach contexts.
…
https://panache.nu/blog/giving-phoenix-contexts-some-context
7 Likes
So reading your blog post @Qqwy, Contexts are just dedicated modules for functionality that can easily be classified as a group (and perhaps optionally) extracted from one big module?
(I haven’t got to learning Phoenix yet so please excuse my ignorance.)
Yes. As stated in the summary of the article:
A context is just a module, with some functions. Internally, a context module might call other modules with other functions. But the consumer(s) of the context do not care about that.
The fact that they are in a folder of their own maybe containing other modules making up the guts of the context is an implementation detail the consumer does not have to care about either.
They are not more complicated than that. 
1 Like
Thanks for feedback @AlexMcConnell. In the future, please try to be less negative and more constructive with your feedback
I would also love to see you edit the title to something more constructive, like “Contexts may be a barrier to entry for newcomers” or something less inviting of inflammatory discussion.
I reject your premise that trying to help newcomers design their app with well defined modules and functions will spell an end to the success of Phoenix.
Since generators are learning tools, it’s exactly our goal to encourage folks how to build applications. Design patterns have no bearing on this and someone’s knowledge of them has nothing to do with their abilities or their potential success with Elixir and Phoenix. I don’t see this part of the argument. Just as our Channel generator doesn’t force folks to first learn OTP to use channels, context generators don’t force people to understand patterns or have a degree in system architecture. When a newcomer sees a generated handle_in(event, params, socket), do: {:noreply, socket}, we aren’t forcing them to know about stateful servers and GenServer reply values, but as newcomers sees this code and experiment with it, they are internalizing concepts that underly the runtime. In that same light, our goals with the context generators aren’t to force folks to be system architects, it’s to guide them along a path where they will internalize ideas about Phoenix as the web interface to “their app” and think about isolation. So when they see:
defmodule Blog do
def list_posts do
Repo.all(Post)
end
end
defmodule MyApp.PostController do
def index(conn, _) do
render(conn, "index.html", posts: Blog.list_posts()
end
end
They’ll start to understand, “oh, this is where I write my code, in modules and functions, not inside the Phoenix web bits”. We aren’t asking them to take a giant leap, rather baby steps along their way to isolated systems. We don’t expect them to get there immediately, but rather nudge them along the path to greater understanding.
Again, as this feature is a learning tool, we indeed are trying to educate newcomers on the virtues of these ideas, but we aren’t forcing anyone to understand or use anything in particular.
The framework is a couple years old now. Let’s agree to set a reminder in our calendars for two years from now and we can evaluate how things played out [quote=“AlexMcConnell, post:1, topic:5929”]
I’ve seen a lot of people saying, “Phoenix is not your application.” Well, stop it! Who are you to tell someone what their application is or isn’t. If they don’t understand the concept, repeating a catch phrase over and over isn’t going to fix the problem, it’s just going to encourage them to move on to something else with a community where people are being helpful rather than condescending.
[/quote]
As a community I think we do a fantastic job onboarding newcomers and avoiding being condescending. I do agree we can do a better job here with that phrase, but in my experience the folks using these phrases aren’t just chanting them, they are helping folks understand the concept. After all, the “Phoenix is not your application” talk by Lance (Phoenix core-team member) was all about the reasons why this is important and how it can help you.
This is what your OTP application is for, so introducing "app would have the opposite effect of what you’re hoping for I think. Also keep in mind that if a user’s app is trivial and named something like “MyBlog”, they could use their MyBlog base module as the “default” context. The generators are aware of existing files, so the context code would be injected in place. Something like that in the guides could maybe be a happy medium?
To be fair, constructive criticism is welcome and I think we’ve had a good bit of decent discussion in other threads, but most of the context feedback so far has been far from constructive. Instead of basing arguments in the abstract about somehow pushing folks away if they aren’t experts, it would be far better to talk around code and actual points of confusion. For example:
Instead of:
Contexts are terrible because newcomers will struggle. IT"S LITERALLY THE DEATH OF PHOENIX
We’d like to see this:
I’m struggling with Phoenix 1.3. I can’t decide where to place comments and votes for my Articles system. Should it live in my current Blog context, or be separate?
I just answered a comment like this on slack, and after asking them about their app, I recommended they create a ContentTracker context for tracing comments, votes, and page view statistics about entities in their system. We also discussed that they could add comments/votes to their Blog and there’s nothing wrong with that, but they were quite pleased with the ContentTracker ideas and it made thinking about boundaries really click for them. They wen’t from frustrated to epiphany and appreciation after just a little bit of help, which is our whole goal with the getting started process in general. It’s easy to argue in the abstract that something is good or it’s bad, but it takes more effort to actually present scenarios and come to a solution together. I’d love to have more of the latter
12 Likes
I totally agree I should have more experience before I can say anything that has more meaning than just a feeling but as you may have noticed I’m already an Elixir + Phoenix fan and I would really like to have the time to test them.
I am happy to see that you as the creator of Phoenix have accessibility in mind and I guess when I will finally have a chance to write my first API with it I can give a more constructive input.
What I wrote was just the feeling I get from this whole thread.
I still remember when I first tried to create my API gateway using Rails and how frustrated I got on the inability of the framework to give me what I wanted, so I ended up using Sinatra (which was a better fit and what I should have used from the start)
But I can still remember how 10 min after I started working with Rails I basically had a working web app, this is the kind of accessibility I would like to see in Phoenix - mainly because that is the framework I see the most potential in, this is regardless of context (which I think I’m going to love from what I read about it) I already have a web app in mind.
1 Like
When I first discovered Phoenix, I fell in love with it because I understood it easily and got productive with it quickly because of the official guides and the Programming Phoenix book. When I grokked it, I was able to build three web apps in just a few weeks.
When Phoenix 1.3 and Contexts were introduced, I got more excited because I really think this is a good idea. So I began to try to learn and understand these new concepts. However, the official guides and the Programming Phoenix book haven’t been updated yet for Phoenix 1.3.
I have been stuck since. I haven’t even worked on improving my apps again. The introduction of a new concept without proper guides really has been a huge barrier for me to continue learning and using Phoenix.
I really really hope that the official guides and the Programming Phoenix book will be updated very soon. I have been stuck for a while now.
5 Likes
We’re working on the guides now, and the book work will follow. Do you have scenarios you can share where you are stuck? You said you “fell in love and got productive quickly” – even if you are having trouble without guides/books on 1.3, you can continue to enjoy your progress on code produced by the <= 1.2 generators, no?
1 Like
I feel like it’s not only the scenarios in detail, which make people feel stuck when starting with 1.3. From my own experience it was rather the fact, that Contexts ask you to bundle up things before there are things to bundle and at a time, where you might not even know enough about which things are related and which aren’t. It’s asking for a decision, which you can do best after getting your hands dirty, but before generating the code you could get your hands dirty with.
And a related issue is schema association: If one finally setteled on some initial contexts (potentially still doubting they are correct) the next worrysome thing comes around the corner. Directly associate schemas across context or not to do it.
My takeaway would be the need to tell new phoenix users: “Don’t worry to much about context initially – think about them, but do not worry. (Even a ‘Core’ context is fine to start with.) Context most certainly will evolve/change; refactoring is simple in a functional language; so get your hands dirty and if better contexts emerge, refactor. No need to get it right from second 1.”
9 Likes
I know you’re working on the guides and the book. I am patiently waiting. Thank you so much for all your hard work. However, it would be really helpful if you published more articles or videos, even short ones, to help us achieve the correct mentality on all of these. Help us think how you think.
I learned Phoenix by using your book and generators. It was really easy to follow. Code in the book + code produced by generators = best practice. Or so I thought. What I now understand from your talk and your comments is that generators are just learning tools. After learning, we should stop using them. I’m the type of programmer who struggles to start a project on a blank slate. So this is a stumbling block for me.
Since my projects are still in the early stages, I prefer to continue working on them after I understand the correct way of doing things. The main thing for me right now is how to organize and name my modules and functions.
Thanks.
In my experience, when expressing a minority position in a community, it’s necessary to express that opinion very strongly in order to get others who share that position to speak up and see it actually addressed. People don’t like to disagree with the group, particularly when it’s against the biggest names in that group. My OP may not have been as constructive as it could have been, but it has led to a very constructive conversation, and that’s what leads us to the best result.
1 Like
That may be your experience in other communities but it really isn’t the case here.
You are correct in saying that your OP wasn’t as constructive as it could have been, but the fact it has led to a constructive conversation reflects on the community much more than the way you worded your post IMO (this is evident by all the other threads on this topic or indeed any topic on this forum) 
With that said, I have changed the title to better reflect your argument, that contexts are a potential barrier for newbies. Please also remember that we are a drama-free forum, criticism is not only welcome it is encouraged - so long as it is constructive and amiable.
4 Likes
I do think something like this is important. I think the difficulty of creating a noun is perhaps being underrated a bit here.
People often start an application on the basis of a story. They want to be able to do A, B, or C with X, Y or Z. They barely know what entities really need to be in their system yet, nor exactly how those entities will do in order to make the story happen.
With all the intrinsic blurriness of an early application, placing the question “What noun best encapsulates this code” is, I think, a genuinely difficult question. It’s not for nothing that “naming things” is often referred to as one of the harder things in computer science.
14 Likes
You edited this comment, but original quoted below:
This comment saddens me.
This rationale is a recipe for burning out maintainers and making the community a less welcoming place. Please reconsider this position.
We’ve had constructive conversations on this forum and elsewhere by folks asking for help and receiving it. The only thing this line of thinking leads to result wise is me waking up to “X is terrible, the is the end of the success of phoenix” and spending my mornings dissecting what valid points, if any, I can glean from a discussion. It also invites pile-ons from folks wanting to express distaste for feature X. That some folks appear with legitimate confusion and get constructive help is merely a reflect on the community, not some tactic to get feedback from the crowd.
100%
16 Likes
Yes, precisely. I was able to join the conversation only on my third or fourth draft because my first attempts at replying were not quite positive and I discarded them. That’s time I wish I could spend elsewhere. Other times I won’t be so disciplined and write an unwelcoming reply, which certainly won’t help the discussion. Or I may just not join the discussion at all.
14 Likes
When Phoenix 1.3 and Contexts were introduced, I got more excited because I really think this is a good idea. So I began to try to learn and understand these new concepts. However, the official guides and the Programming Phoenix book haven’t been updated yet for Phoenix 1.3.
I’d like to add that this has been true for me as well. As an beginner-to-intermediate-level coder, I want to know that I’m learning things “correctly” - as in best practices - as opposed to piecing things together and somewhat feeling around in the dark, which can be disheartening. (The fact that generators aren’t necessarily best practice, as most would assume, adds to this)
When it comes to Contexts, an example of this is when in this thread Jose wonders:
I wonder how much cheating would it be to do something like mix phoenix.gen.html Posts Post “posts” … for those cases.
I wondered the same on Slack about a month ago, and Chris responded saying that this (Context and Schema having the same name) is likely not right - and there’s probably a better context name out there for me to find.
In my dream scenario, the core team would build out their own complex (not just Blog.example) example app with multiple contexts, shared schemas, etc. To get a sense of what you think about naming standards, associations, etc. Even if it comes with a disclaimer or caveat about how every app is different, this would help give newbies a baseline/starting point.
In my super dream scenario, Phoenix would adopt an approach similar to Ember’s - where guides and features are released in tandem, and there are periodic updates on what the core team is thinking and working on: Ember.js Blog
Thanks so much for the work you do @chrismccord, @josevalim, and team!
9 Likes
My best advice in scenarios like this - when someone is not respectful or constructive - is to just ignore their post/thread (and for everyone else, to flag it for the attention of a moderator).
I’m not saying that this is the case here (I don’t believe it is)… but there will inevitably come a time when some people will come on to post in a contentious manner just to get a raise. It’s best not to fall in to the trap of responding in kind(2) and have it tar your (and the community’s) otherwise exemplary reputation 
Thankfully I haven’t seen any WUMs here yet 
With regards to this thread, I feel the OP just thought this was the best way to get their voice heard. Hopefully we’ve highlighted that it is not; it’s always possible to articulate your thoughts in a robust and persuasive way without alienating the very people who you are trying to get help from.
I would suggest to see what people at Hanami community are doing, something along the lines of what you proposed.
If I understand contexts correctly, I think most people wont really appreciate them until they work on a Rails project that has a 500+ line model file not including concerns and other classes that get pulled in or inherit from that model. But when that does happen it will be a whole lot easier to maintain and extend. Keep up the good work guys 
6 Likes
Ok, I’ll try to think about that more in the future.
I wasn’t talking about getting constructive help so much as having a constructive conversation about the feature. After thinking about it more, I do think that my approach is likely a negative for those who are looking for constructive help.
2 Likes
