Many thanks, that helped me a lot. So can one say that creating a different user schema (referencing to the single “real” user table) per context is the best/preferred way to go when not all data of a user is needed in a context? 
railsmechanic
0
brightball
I can’t comment on “best” but I can say that’s what I would do.
I tend to look at application design from the database out in a very normalized fashion. At the application level, just think of contexts the same way you’d be thinking of writing a SELECT statement if you were specifying only what you needed. It seems less important with the smaller columns, but leaving out giant blobs of text from an object mapping when you don’t need them is healthy for your application.
I personally wouldn’t start putting things in separate context-specific tables unless the database design itself called for it or unless I was performance tuning for some reason (lots of indexes on a single table so we needed to isolate them, for example).
That’s just me though. I’m very much a “database first” style developer. Some people design interfaces and screens first. I design my database first.
3
railsmechanic
StefanHoutzager
You might be interested in task-based ui’s. There is more than the CRUD ui, with relational db’s.
Modern applications typically have task-based user interfaces. A properly designed,
task-driven user interface guides a user through a process, resulting
in a much better user experience.
In order to get to a task-based UI, designers need to answer two questions:
How do the end users want to use the software?
How can the software guide the users through these processes?
A bit of my own fascination (I assume the article in the link has been read already, otherwise the following
text might not make sense at all):
BPM brings the task-based UI to a higher level by adding
1. User roles to a task
2. Expiration moments
3. Decisions / ruletasks, servicetasks, realtime events
4. Low code executable modelling
5. Dashboards for performance management
1
StefanHoutzager
Ok, “CQRS! DDD!” (Those buzzwords must ring a couple of bells)
One of the largest problems seen in “A Stereotypical Architecture” was
that the intent of the user was lost. Because the client interacted by posting
data-centric DTOs back and forth with the Application Server, the domain was
unable to have any verbs in it. The domain had become a glorified abstraction
of the data model. [..]
Many examples of such applications can be cited. Users have “work flow”
information documented for them. Go to screen xyz edit foo to bar, then go
to this other screen and edit xyz to abc. For many types of systems this type
of workflow is fine. These systems are also generally low value in terms of
the business. In an area that is sufficiently complex and high enough ROI
in order to use Domain Driven Design these types of workflows become unwieldy.
1
Shrike
You should remember that the same newbie can choose between Rails which doesn’t require him to learn all those concepts.
Now I ask you as a newbie which framework you would choose.
This is the main issue I get about this whole thread. Most of the ppl adopting Elixir are experienced developers so framework accessibility is not one of the main issues they encounter, learning contexts is easy when you are already familiar with programming but for a newbie those concepts are hard.
Phoenix should be accessible to anyone as easy as possible, yes contexts should be part of the best practices of the framework but they should only be a “best-practice” idea and not the main focus of the framework.
I’m writing this as a newbie developer that has 2 years experience with ruby (not Rails) and 5 years with perl and can see all the beauty in Elixir and I can’t wait to do the move(well I call myself a scripted)
Another thing that bugged me was that a lot of ppl here are missing that most developers never see the business part of their web app and only see their side of the problem so how can you really expect them to see most of the benefits of adding contexts.
Ps - I’m writing this after having only 2 days of experience with Elixir and 2 hours with ecto but never even looked at Phoenix - I think you need an opinion of an outsider because you totally miss that side.
Ps2 - I do understand that contexts are the right concept and should be encouraged but not at the price of accessibility - I am totally going to use it when I would write my rest server for my new project(if it will ever be built)
PS3 - sorry I choose this specific post to reply to but the concept is the same to 90% of what is written here I fell on you as I finally got the true feel of what I should write.
0
chrismccord
Creator of Phoenix
One of my main goals since I got involved in Elixir was to help make the ecosystem as accessible as possible for newcomers, since that is what will ultimately make the language successful – Getting folks in the door and keeping them around passed the FP frustration gap. I’m also aware that many folks are coming into to Elixir thru Phoenix, so trust me when I say accessibility is on my mind.
Contexts are not the main focus on the framework by any means. They are only used with our generators and solely about learning tools for folks getting started. There is no Phoenix.Context.
Welcome! We place huge values on the opinion of folks getting started, so your input is appreciated. That said, please realize you just stated you haven’t looked at Phoenix yet, but you are taking a negative stance on contexts without being familiar with the framework or the generators. What would be very valuable for us is if you provide feedback around using the context generators as you’re learning Phoenix. As it stands now, you’ve taken a negative stance without even evaluating things 
4
cmkarlsson
I don’t think “newbies” would have a problem here. I think the people you may struggle is people who are used to other web application framework such as Rails, Django or similar. Because they are used to another way of thinking.
The problem I have with “Context” is the word. It is made into some big concept that you must learn and that scares people away.
In elixir you have modules and function. Some functions have to be made public. These are your API. Ideally you want your API surface to be as small and to the point as possible. You also don’t want to leak any implementation details out from your API.
By implementing too much in your web layer (controllers) you don’t have a clean API surface and you bleed implementation detail (underlying database concepts for exampel).
Note though, it is hard to come up with the right abstractions. And this is not something you should start implementing straight away. As someone else said it is OK to start with one context and work from there. Only after you “know” your application you are able to make the right abstractions.
The one thing I do know is that separating the presentation layer (phoenix) from your application will pay off.
WIthout proper modularisation and API design (which is what context is about) it is like developing javascript without any modules and just like loose functions on the window object. It works for a while and as long as your application is small but will give you nothing but hurt later on.
I original looked at phoenix some years ago and the apparent lack of contexts (i.e their generators produced bad practice code) and some of the lacking features in ecto was holding me off it.
But I see the phoenix team moving in the right direction all the time and they are not afraid of admitting they are wrong and can change. The idea of contexts is right but perhaps the communication of it has not been the best (if you look at some of the confusion it causes).
5
OvermindDL1
That is my only issue with it too. I’ve never seen Context used in this context before, but rather just normal separation of concerns whether via namespaces in C++, modules and submodules in ML languages, modules in Python, etc… etc… It seems to be a very common pattern that should just always be naturally done, so to this day I’m still confused why it has the special name of Context, or why it is really talked about at all when it should just already be done and used as it is as is normal programming and keeping a Separation of Concerns. ^.^;
But yeah, Phoenix’s generators were a bit noisy and put way too much in the controllers, I stopped using them very quickly and not touched them since. It is good that they do that separation of concerns, but I still do not think it should be called a context, even the word Concern would make more sense but I do not like it either… :-/
10
sasajuric
Author of Elixir In Action
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