I am exploring some ideas similar to @baldwindavid’s TokenOperator (wasn’t aware the library existed when I started). The API is slightly different, and I’ve not tested it on production yet, so for real production usage TokenOperator is probably a better fit, but it looks something like this (Midas is placeholder name for now).
defmodule Blog do
def list_posts(opts \\ []) do
Post
|> query()
|> Midas.new(opts)
|> Midas.add(:id, fn q, %{id: id} -> queryable |> where([q], q.id == ^id) end
|> Midas.add(:user_id, &user_id_query/2)
|> Repo.all()
end
end
I took some inspiration from Ecto.Multi and Absinthe, using Multi’s token approach and Absinthe’s resolver idea, I think the API looks rather clean while being pretty obvious what is happening when you read the context code. You are declaring options, and have resolvers that can resolve these options (just like how absinthe resolve fields).
My ideal usage would be to hide the query logic from controllers/absinthe resolvers, I don’t think they should know about what queries to run, so I disagree with baldwindavid’s approach where the controller specify queries to run. That way controllers only talk to the context function, and it doesn’t actually know how the data is resolved (whether it be Ecto, API or something else).
My current usage is to definite a lot of named functions, (list_published_posts etc), and then reuse and compose Ecto queries, this just sort of simplifies it into one interface.
Maybe this can give you some idea.
