Contexts had me confused as well, I still don’t understand them fully. I’ve settled on something simple that works for our application and is good enough.
When starting new application, I needed a simple CRUD for users. To jump-start, I used:
mix phx.gen.json UserAPI User users email:string password:string scopes:array:string
Among other things, I got this folder with two files:
lib/my_app/user_api/user_api.ex
lib/my_app/user_api/user.ex
I found that having context with a name UserAPI is an absolutely amazing starting point, because:
- File
user_api.exis now my dump pipe for alluser-related code, - schema file
user.exremains clean and un-touched, - I use the
user_api.exdump pipe until I figure out some of the code is good to go into a module of it’s own, - As soon as I figure out something needs to be extracted, I created a file nested under
user_api; recently I added a file calleduser_api/search.exthat incorporates validating search params & building complex search queries for my users, - My
user_api.exis now a glue between repo & user_schema and the rest of the app: by our convention no module should be calling functions fromMyApp.Repo/user_schemadirectly.
This maybe be very dumb and simple, but it works perfectly for us.
) with all of my core domain models in one place. So things like “user”, “blog”, “post”, “comments”, “department” and “business”. I then structure everything into areas so the “blog” area will have it’s own controllers, views, view models and services so it is its own mini app. The key to this is the view models which are representations of the actual domain models which can have their own validations, fields e.t.c. but are cast to domain model before going to the database. So like Ecto schema and changesets.
That’s the point. Best practices are guidelines. They are very important for new teams and we will provide more of them to those teams as we go but experienced teams should re-evaluate them when necessary.
