Not sure if this code is best, but at least it does not depend on private API:

  defp do_apply_join({parent, relation} = parent_relation, query)
       when is_atom(relation) and (is_binary(parent) or is_nil(parent)) and
              (is_atom(query) or :erlang.map_get(:__struct__, query) == Ecto.Query) do
    as = join_as(parent_relation)
    query |> Macro.escape() |> join_build(parent_relation, as) |> elem(0)
  end

  defp join_build(query, {nil, relation}, as) do
    Code.eval_quoted(
      quote do
        join(unquote(query), :inner, [p], a in assoc(p, unquote(relation)), as: unquote(as))
      end
    )
  end

  defp join_build(query, {string, relation}, as) do
    parent = String.to_atom(string)

    Code.eval_quoted(
      quote do
        join(unquote(query), :inner, [{unquote(parent), p}], a in assoc(p, unquote(relation)), as: unquote(as))
      end
    )
  end

Notes:

1. Since we are using eval here I have added some guards. To make sure nothing would explode you may add extra runtime checks (regex?) for parent and relation contents.
2. Make sure to add import Ecto.Query and remove unused alias Ecto.Query.Builder.Join and join_binding/1 private function.

Ex_sieve seems very powerful, yet there’s also a simpler library - Flop - also in early dev stage. Kudos to authors and contributors!

Can someone well-versed in Ecto comment about the benefits and downsides in regard to how both libraries approach DB querying, eg. security, performance, query-composing and general dev experience?

The documentation contains some example.

The main use case is to create a filter query on a list view taking as input user supplied URL query parameters. But this is not the only possible use, the Repo.filter function provided by the library takes as input a map that can be built in many different ways.