I got a quick look and it looks interesting.

One thing I would change and I think it would improve quality-of-life would be returning a struct from the turboq function and implementing Enumerable on it to iterate over the results.

The other thing is why there’s the use API at all - I don’t see it giving the user anything they can’t do just calling Turbo.Ecto functions directly.

We’ve just built something similar ad hoc in our project with some differences:
We didn’t want to couple params to DB operations and we wanted to filter on joined entities too,
so we decided to allow custom params e.g.

params = %{
  "q" => %{"shipped_before" => "01/01/2018"},
  "s" => "inserted_at+asc",
  "per_page" => 5, "page" => 10
}

And then for each query we need a callback module that implements the query and filter callbacks.

def query do
  Product
  |> join(:inner, [p], sh in assoc(p, :shippings))
end

def maybe_apply_filter_term_to_query(query, "shipped_before", date) do
  query
  |> where([p, sh], sh.date < ^date
end

And then we apply all filters one by one, add ordering and filtering. Saves nice amount of boilerplate, unifies params responsible for sorting and pagination, and allows for arbitrarily complicated queries

If multiple people arrive at similar ideas, it means that those are good ideas!

@michalmuskala Thank you for your reply, it’s over-design, you are right, I know how to improve it.