Yes, I think we’re in full agreement. My current clients build these types of systems. I mean there’s always some more logic than just store data and display it, but nothing as involved as e.g. a banking system. We actually briefly deliberated about pure model data structures, but they didn’t seem worth it for us.
I absolutely agree that in more complex cases using the underlying storage view for domain model won’t be optimal. I mean, you can always hack around it, but this will bring needless complexity in the app code. So, yeah, in such cases having a pure domain model decoupled from internal db representation is definitely a good choice.
To be clear, this isn’t a shortcoming of Ecto, but rather it’s property. Ecto makes IMO a great choice to keep schemas very close to the underlying db representation, which makes things simpler in the beginning, and is sufficient for smaller domains. For anything else we need to do our own work, and I don’t think that any library/framework can help us here.
So I just wanted to point out that starting with the pure model IMO is an overkill for many projects, and also that such approach needlessly raises the bar for the people who are just starting to use the technology.
My users come to me with a token, not an id, so I do need to fetch the user. I guess I could use a plug here, but I’m not convinced. Also the authorization requiries querying across schemas, so I don’t see how I could stay in one context. Having a slimmed down duplicate of the schema sounds like an interesting idea to try out.
index and show is when things get murky. My controller asks for quite some data, so the dependencies are there - in the controller. I end up with an action that calls 5 functions. I think it crosses the line of being “thin”. Moving this out to a new context just makes it easier to test. But that doesn’t seem to add more coupling.
Understood. I usually have a struct because I have grabbed it to authorize.
They are generally pretty thin, I think. In a lot of admin areas they are authorized at router level, so it is a simple case statement.
Other areas have per action authorization which adds a with. Anything more intensive typically takes place in whatever context function is being called. Some of these functions within the context end up as big multis. In a few cases, a user is passed to the context function for authorization. That is typically to use a different changeset based upon user permissions.
I think as I refactor a bit, I will likely end up with some cross-context, um, contexts. The Phoenix docs talk about this a bit at the end… 1. Intro to Contexts — Phoenix v1.8.8
I appreciate the information and can experiment and learn even if I’m not going to use it right away. It is good to have that as a potential route when I encounter a situation where the defaults aren’t quite cutting it.
To be clear though, I am absolutely duplicating the user name in a Calendar.User schema. I will not be planning to write the user name from the Calendar context, but will definitely read from it. Perhaps that right there is one of the issues with using the same table with multiple schemas though. If you can/should only update a given column/field from a single context, you don’t immediately know in a given context whether a field can be written to or should be read-only.
Anyway, to me, the beauty of the ability to use the same table for schemas in multiple schemas is that I can more easily reason about in whatever context I’m currently in. Quickly skimming the schemas within the Calendar context shows most of the data used in the context. Context-specific authorization can be performed directly on structs within the calendar context.
It’s not to say I won’t/don’t reach out to other contexts/services when it makes sense, but contexts mostly being able to operate on their own feels pretty nice. As a side benefit, it might make it easier to break these a contexts off on its own app in the future. That is not the reason I’m doing it though. It is attempting to (maybe even wrongly) make it easier to understand and, ultimately, more maintainable.
Agreed. Regardless of the direction I’m going now, I don’t feel particularly locked in to anything. Ecto and Phoenix are both light and flexible and changing things often just comes down to changing some module names.
This is a great thread. I’ve had a lot of these questions myself and haven’t come up with answers for all of them yet.
I just wanted to chip in by sharing a link to “Building beautiful systems with Phoenix contexts… by Andrew Hao” https://youtu.be/l3VgbSgo71E which I think has some good advice around getting started with contexts, and particularly on sharing concepts between contexts starting from 22:03.
Thanks for the link! Somehow I’ve missed the guide on contexts and it’s full of great content (thanks @chrismccord!) . I’m actually doing the exact same thing as the UserRegistration context mentioned in the guide.
