Also, atm it’s really hard to decide how an app should be split into contexts. Imo that’s the most important point and everything should start from here. After all the videos, blog posts, discussions i don’t know how to apply contexts correctly (and it should be obvious, for the sake of humanity and developers). Current approach do not solve this
thousandsofthem
thousandsofthem
Well, don’t know, proved to be hard question.
Also, see comment above - how about putting other parts into context.
Also, like mentioned earlier, something like Post.Post "posts" isnt really useful 
maybe shared/global context? (Going to become garbage bin though)
0
Ankhers
[quote="thousandsofthem, post:44, topic:5929]
contexts in the way they are now are terrible.
[/quote]
Would you mind elaborating on this a little bit? What about them do you think is terrible? What would you try to do to improve them?
2
thousandsofthem
I’m agree with topic starter - contexts in the way they are now are terrible. On other hand, some other way may be godsend. Also, for me, contexts make much more sense for controllers (e.g. separate context for public area, for account’s private zone, admin area), for various helper modules/services, for wrapper methods around schemas but not for schemas itself
1
bzhr
Phoenix isn’t Rails. Rails is good for what it’s good and it gives the biggest head start for some kinds of projects. New programmers can get most done with Rails with these kinds of projects. Phoenix is like Rails for programmers looking for an easy entry into the world of concurrency and microservices (separation of concerns). It is very obvious that these two concepts will be key strengths for programming languages in the near future. With other languages you need to do so much planning and analysis to properly separate concerns and get maximum computational power, while with Elixir you get it out of the box.
I think that Phoenix is like Rails for concurrency/microservices. Add on top of that pattern matching and functional programming which are massively taking over each programming field (mobile, front end…) I think that Phoenix/Elixir is in the best possible position.
4
aseigo
Given the questions I see here and elsewhere, while contexts may be a stumbling block for some people, the real barrier appears to be Ecto. The hardest questions, often with the fewest answers, tend to be ones about Ecto.
Querying structured data is not the easiest thing in the world, and trying to create a nice abstraction between the storage system and your application is not easy. Ecto itself has been evolving rapidly, and so there are a few More Than One Way To Do Things, and many rough edges to be found (I created a pull request for one of those just 3 days ago).
Ecto is awesome, but it isn’t perfectly easy. And the amount of high quality examples out there is not .. encouraging. Most cover the simple things (as someone else noted, real world use cases are rather more complex). .. yet we don’t really hear toooo much here about the complexity of Ecto and how to make it more approachable.
So for me, worry over context is a sort of classic “bikeshedding”: contexts are easy to spot as a bump because they are new. New things without clear and unambiguous (perceived) benefits are often perceived as bad, or at least uncomfortable, at the start. Contexts are also somewhat trivial: they don’t REALLY introduce a new concept to the language or even the framework. You could have been doing something like contexts before, and you can ignore them now. So they aren’t really .. critical. Contexts are also easy to understand and have been highly exposed.
So there are lots of discussions about them. Losing too much energy over that discussion is probably not useful, especially when there are bigger fish to fry out there such as Ecto.
What I think is likely to resolve the issue:
- time (as @josevalim noted already)
- a clearer statement and understanding among us developers what the purpose and benefits of contexts really are
- some nice examples / tutorials to show the path (as others have noted, having trailblazers to follow helps a lot more than documentation and marketing alone)
This is not to say that contexts are not a possible problem for newcomers. They may well be. And if people are saying that they are a problem for themselves, I think we have to accept that as true.
What we don’t know is what % of people coming to Phoenix are finding contexts an issue, for how long that persists, if it is a blocker, and/or what other issues are more important to them. Personally, I would very much appreciate a developer feedback survey that we could use to gather some data to understand what really is going on 
9
massimo
If I understand this correctly, the problem is that newbies don’t get best practices and find somewhat hard to comply.
But isn’t it that the reason why they are newbies and we set up best practices ?
When I first bumped into Rails I was already an experienced programmer, but I had been working on .net and weborms for years and it was really confusing for me at first.
Rails wasn’t easy at all for newbies, but it was opinionated and that made feel other’s people code familiar and helped expanding the knowledge.
What’s easy now has been hard at the beginning.
Practice makes you perfect, I strongly believe in the value of enforcing good behaviours instead of being too permissive and allowing the big ball of mud to prevail.
6
josevalim
Creator of Elixir
I wonder how much cheating would it be to do something like mix phoenix.gen.html Posts Post "posts" ... for those cases. Although I can see that if you are going in this direction, then contexts definitely feel like boilerplate.
0
LostKobrakai
That one is an issue I noticed as well. While I feel it’s good to have people think before diving deep into details it surely feels like a blocker as well. But in the end everybody is free to simply use the context “Core” or “App” for as long as the contexts are not clear enough.
That’s one reason why I’m hardly using the generators anymore. Creating the modules manually is often as fast as (remembering the correct cli syntax and) deleting all the generated crud stuff.
4
nerdyworm
I’ll be peeking at the hex example: GitHub - hexpm/hex: Package manager for the Erlang ecosystem. · GitHub didn’t know that was a phoenix app
For some things, absolutely it’s been super nice and clean to work with, credit where credit is due.
For other things, it feels like one layer too deep from the web app. It’s like I’m forced to wrap every call to Repo.update with NotARepo.update. It’s clean when it’s needed, but when it’s required it’s tad overly formal.
Get rid of create/update/delete/list/get/exists function names and replace them with names that are meaningful to the context. For example, Scheduler.meetings_this_month Post.submit_reply Calendar.add_reoccuring_event. By my count that is a context name, the database struct or whatever the context trying to abstract, and the function that defines the interface to the rest of the application.
It’s those none crud things which bring the most value to contexts, however, only a small percentage of my application really benefit from them.
The most concrete issue that I deal with is when the database table is just a database table.
In my little project, I have about 60 schemas and growing. 20 of them are purely just a schema/database table. The fun part is that any of those 20 schemas are fair game for any other part of the app to depend on, have reference to, and have collections of. I guess the app is the context for these things?
The second issue is when I start a new project that is when I know the least about it. It is pretty hard to divvy up an app into meaningful parts when you are not exactly sure where things fit. Some sort of blessed dumping ground like lib/core or lib/schemas and some tools to refactor to contexts would be very welcome.
Thanks for all of those participating in these threads. They can get heated but I know it’s because everyone deeply cares about the tools they are using. I’d be worried if everyone just went with the flow around here.
Cheers!
3