" it doesn’t really matter as long as the way you split your contexts is reasonable and understandable."
Best suggestion since one of the weaknessess of context for maintenance is youwill have to rely on human memory of how you broke contexts up. You are terribly unlikely to come back to an app and remember those decisions if they are over thought or too minutely considered. I’ve learned to live with contexts but still not a fan so I keep them simple and not fine grained.
A better way to say this is that you need to rely on domain knowledge for how the application is structured. Contexts give you a directory structure that helps with a 1000 foot view of the system, and good naming strengthens this, but ultimately the finer details of “why is X here and not part of Y, and why does it talk to Z” is really domain knowledge that often leaks outside of the code itself over to this business you’re powering. So rather than a “weakness” I would say it’s a reality of any new team member coming into a project. The goal is instead of relying entirely on memory of passed devs, you have some architecture that screams its intent to help fill those gaps.
Chris the way I said it is fine. I dont need language correction on my own viewpoint. We simply disagree that contexts adds anything vastly better to the programming world and as this thread proves it still confuses people. everyday I and tens of thousands do just fine building and structuring our apps without it. We have found ways to structure and think about our apps that are far more intuitive, less over thought and easy to pass on to new team members and come back to. Whenever i see even ten top trafficked sites on the internet claim they can’t live without your concept of contexts I will stand corrected but alas today is not that day.
“The goal is instead of relying entirely on memory of passed devs, you have some architecture that screams its intent to help fill those gaps.”
Then it fails. contexts do not scream anything to a new developer. It would if there were one way that you could relate to yoru app and its architecture but contexts is highly subjective to how you view your app and business. We see this every time someone asks about how to use them. There is no one way to think about contexts in any app so it screaming to any dev is an illusion.
Sorry I came off this way. I’m not attempting to correct your language, rather expanding the discussion on what you view as a weakness.
Not sure if you’ve seen the context guide or any of my talks on these points, but there’s no productive convo forward if I"m only rehashing those points
The last thing I’ll say is contexts are only a starting point and we see confusion because architecting programs in general is a hard problem with no single rubric to apply. Different domains require different solutions and folks may be really thinking for the first time about structuring their greater app.
Fair enough. I appreciate you didnt mean to correct language even though thats how your sentence was written. I have read the guides and I can work with contexts. I just don’t find them as good a solution as you claim them to be. So its not ignorance like I said - simply do not agree. No need to rehash your points because I know them so they would make no difference.
“The last thing I’ll say is contexts are only a starting point and we see confusion because architecting programs in general is a hard problem with no single rubric to apply.”
perhaps i work with too many languages and frameworks but I dont see this being an issue that is driving the programming world into the ground without contexts. So no I don;t see this confusion except in regard to contexts. Instead I see evidence contexts have a tendency to make people overthink and get bogged down in paralysis as to whetehr their contexts are “right”. As an example I build apps in Django that work fine, are relatively easy to figure out but are structured at the level of apps. I have no doubt that Phoenix faithful would consider them inferior but agian until Phoenix is powering some of the apps dajngo is and doing it better with contexts I’ll remain less than impressed at contexts’ superiority. I’ll leave it there as well.
I’d be interested to hear more about the strategies you apply to structure your own apps that provide these benefits if you’re not using contexts (namespacing modules by business concern).
I suggest that without separation of concerns, apps often turn into monolithic great big balls of mud. Search for monolith and Rails or Django to see how much pain that causes.
By deciding to segregate your app by its business area from the outset, you invest a little more time thinking about the structure to ensure modules are highly cohesive within a context but contexts themselves are only loosely coupled. This allows you to extract a context into its own app, or its own standalone service (microservice) as usage and/or requirements dictate. It’s far easier to follow this path if the separation exists from day one as the boundaries and public API have already been defined and used.
“I suggest that without separation of concerns, apps often turn into monolithic great big balls of mud. Search for monolith and Rails or Django to see how much pain that causes.”
and yet apps that dwarf any usage by phoenix particularly Django continue to thrive and do well on the internet and have not come running to phoenix bowing down as their salvation from this unbearable weight. Where is that stampede?
Honestly all this contexts (as applied to Phoenix) are the answer to the great woes of modern day programming are quite over the top and to be honest - somewhat arrogant. its one way to think about separation of concerns and frankly in some cases the separation of concern arguments (though not quite applicable to this ) are over stated. One of the things we are seeing is that when you slavishly try and maximize this separations of concerns you end up with muddled mess in the minds of the developer. You have him/her sitting down even with small apps trying to see how many times he can parse his poor little app that out in the rest of the world doesn’t need all the separation. If he’s really good he might come up with 27 contexts to build a cart.
So you sincerely believe that you can’t muddle up contexts as well? Believe on. One of the reasons why you can believe this is because Elixir and phoenix are young and it generally takes several years before any design decisions manifest themselves either as not solving an issue or as outright mistakes.
Mind you I guess I am not in the mindset many here are - I see similar argument in regard to functional programing being the great rescue of programming and how awful OOP is. You all might be right but like I said to Chris theres going to have to be a whole lot more popular apps built in phoenix before anyone can claim to have solved all the other problems that poor old programmers on other platforms couldn’t solve. Theres an actual track record by those programmers and paradigms with apps the whole world rely on and enjoy
Me? I use Elixir and phoenix for concurrency benefits not because I think every single design feature in phoenix is the next coming of sliced bread.
Here’s one more thing about contexts to consider: the implementation that the Phoenix team pushes mixes the infrastructure with business logic.
For me, phoenix controllers and schemas are merely a pieces of infrastructure. If there is business logic in it, that’s a sign of bad design. Controllers are responsible of handling the HTTP layer, redirects, passing parameters to and from business logic services. Schemas are only mappers to database tables. Both are interfaces to external world, world outside of the application you are building.
And in my humble opinion, they should match the characteristics of outside world. In case of schemas, the databases are usually flat, with tables living in the same global namespace. In case of HTTP requests, we do have namespacing in form of URLs, i.e /settings is on the top level but /posts/123/comments could be namespaced into Ui.Posts.CommentsController. If I used database that allows nesting tables (lime MongoDB), I could namespace my schemas the same way too - but luckily I don’t.
My main point is: infrastructure is not business logic, and should not be mixed conceptually with. Luckily, we all don’t have to agree on these thngs, Elixir/Phoenix is flexible enough for us to have different approaches.
I specifically asked what advice you have and app structure you employ to build apps that provide the benefits stated (intuitive, easy for beginners, etc.) if you aren’t using contexts?
“I specifically asked what advice you have and app structure you employ to build apps”
Not liking your tone. Its quite bossy (and no one here is even close to employing me) rather than having a discussion. However If you read the thread you would see specific answers.
A) you’d see I said “I’ve come to live with contexts” (in phoenix) so your assumption I dont use them at all is false, I just don’t use/overuse them to the extent suggested - as hubertlepicki rightfully points out “Elixir/Phoenix is flexible enough for us to have different approaches.” . That includes not seeing them to have the same merit as the Phoenix team does.
B) you’d see me use the example of Django apps. Many apps don;t need anything more and are not dropping down into any ball of mud as you allege
C) I think I have stated SPECIFICALLY the issues I have with contexts. Like Chirs early stated “there’s no productive convo forward if I"m only rehashing those points”
NOw that I am past the lawyer interrogation stage of what you specifically asked for perhaps you can specifically answer mine. Where is the stampede to Phoenix and its conceptualization of Contexts since allegedly they all have fallen into a ball of mud without it? Its a very tall order to claim that Phoenix answers how you structure yoru app and seperate concerns where the rest of the programming world, all the fine frameworks that have built so much more and thousands of outstanding programmers have failed but though you might deny it - that s pretty much the end point of what you are saying and its a pretty arrogant claim for any framework or its adopters to make. That requires some proof. have any that this way of ordering your code is THE way that solves all these problems ? Proof being the SPECIFIC question.
Except that we are not saying it is the solution to everyone’s problem. As Chris said in this thread itself and in many others, we know quite well we can’t prescribe a solution for everyone. We believe it is better than what we had but it certainly isn’t a panacea and you don’t even have to agree wth them. You are free to roll with what you prefer.
I might be missing some point, but since when has modularizing software become a controversial subject?
Everybody is doing it one way or another, except everybody is calling it slightly differently. Contexts aren’t nothing new or exceptionally innovative, there’s no revolution or “revelation” involved. People were doing “contexts” in their apps for years. The concepts that are the base of contexts are probably with programming since the very beginning. There’s no “truth revealed” involved - it’s merely a formalization of best practices from a lot of communities.
“I might be missing some point, but since when has modularizing software become a controversial subject?”
It isn’t. Its that a particular way and extent of modularizing your code is the way to go. As you suggest modularizing code is ubiquitous and is done in a variety of ways.
“Except that we are not saying it is the solution to everyone’s problem.”
I wasn’t responding to you Jose as that was your first post in this thread but when people start pointing at other frameworks and how they do it wrong - yes they are claiming to solve those problems. its necessarily implied.
But contexts are just that - modules with well named functions. It’s not very catchy, though, hence the name “contexts”. But it’s really nothing more.
It’s a very simple idea and I don’t agree with any of the extreme sides - those presenting contexts as the best thing since sliced bread and the greatest threat to humanity. They are both wrong.
It was said many times, that phoenix’s generators are for learning purposes. Phoenix does not care how you structure you app. I substitute word “Contexts” for “Modules” and it works fine for me.
“But contexts are just that - modules with well named functions. It’s not very catchy, though, hence the name “contexts”. But it’s really nothing more.”
I don’t know contexts are catchy - that was the reason for the name? as a name it tends to present nothing but confusion for some coming from other frameworks and languages. Sometimes being different to be different achieves nothing good.
To your point, of course programmatically, but as often is the case when you highlight design patterns they are suggestive of how things OUGHT to be done. You can see it in some statements made when people ask about context right here in the forums - if that were not so why do many people still continue to have issues with understanding contexts. Most of them are not entirely new to programming where as we agree modularization is nothing new.
Look at the questions that arise on this forum? it s not that contexts is merely suggsting to them modularization but really has them in a state sometimes of paralysis as they wrack their minds as to how far they should “seperate concerns” to be in keeping with what contexts are suggesting to them. We have people obsessing over whether user has to be within accounts or accounts should be in user in apps that sorry at least some in fact most of the time - it will make no huge difference.
I can accept that was not the intent but you can see somewhere that reality was suggested to them intentionally or not. When we have the community pointing at other frameworks as faulty it only strengthens that impression
I do thank you for the last paragraph and its balance. Its probably my biggest objection since doing work for startups of to others and myself its not practical for me to approach development like that.
"Phoenix does not care how you structure you app. "
Thats for practical purposes false and demonstrably so from some of the comments in this and other threads. A practical part of every framework is its community and ecosystem esecially to a young framework with new adopters.
Anyway enough of this discussion for me. Said my peace on it.
Asking you to enlighten us with your ‘better’ approach was perfectly acceptable, your response above, is not.
This is now the third time I have had to comment about your conduct on the forum. There’s absolutely no need for any kind of hostility or antagonistic behaviour - it’s perfectly possible to have a discussion or debate about something without resorting to making personal remarks or lowering the tone of the discussion.
As my polite requests asking you to review our guidelines and to keep your posts civil and amiable have been ignored, I am suspending you account for 30 days. If on your return you continue to post in this manner your account will be permanently closed.
© Copyright Elixir Forum | Terms | Privacy & Cookies
