This pattern is very similar to ActiveRecord, the ORM from Ruby on Rails framework.
Basically, you can do things like this
User
.where(is_admin: true)
.order(email: :asc)
.update_all(ia_admin: false)
The context approach is something different, you abstract all the query construction behind the semantic function name and you can explore all the queries just looking into context files.
If you’re going to create “meta” contexts then we’ll go back to the ActiveRecord pattern where queries are constructed elsewhere in your codebase but not in one single place.
Both approaches have pros and cons but I don’t think mixing them is a good idea. For me it’s two completely different things because in one case you have “the right way” and you’re overindulging yourself in all king of helpers and pre-generated code.
I can’t find it right now but can remember when rails had code like def seven(), do: 7 and you could write seven.days.ago or something similar. It does create pleasant experience but empirically it’ll end up in a codebase which is implicit and challenging to maintain.
On the other side, I comprehend Elixir approach like be explicit, be flexible, allow user decide what is best and how to approach problems and it work best when you’re experienced engineer. Finally, we have configurable, explicit and flexible interfaces in Elixir ecosystem.
