The main benefits of this library are the same benefits of GraphQL – declaratively fetching data, frees you from thinking about the implementation details of how that data is cobbled together. The exact shape of our database almost never matches what the end user sees. As you said, sometimes data is ephemeral, derived, excluded, pulled from other sources/APIs, etc.

I don’t know of any other solutions for this. Ecto has preload for the database layer, but it doesn’t solve the problem described above. And of course there’s the absinthe library, but that’s if you’re using GraphQL.

A lot of what I see goes like this: A requirement comes along to ensure deleted users aren’t removed from the database. So instead of using Ecto directly, a function is created:

def fetch_user(id) do
  User |> where([u], u.id == ^id and not u.deleted) |> Repo.one()
end

Devs can use this function and not have to worry about how a user is fetched. There are a lot of growing pains with this style. For example, consider another function that gets added:

def fetch_org(id) do
  Org |> where([o], o.id) |> preload(:users) |> Repo.one()
end

Uh oh, we forgot to exclude deleted users. Also, the caller of fetch_org/1 might not need the org’s users.

With Qry, you’ll write the implementation functions for how data is loaded, then you’ll just use the main query interface everywhere:

# an org with users
Domain.query({:org, %{id: 1}, [:users]})

# just an org
Domain.query({:org, %{id: 1}})

# all users
Domain.query(:users)

In the Domain.fetch functions for fetching users, you’ll exclude deleted users, and know that everywhere Domain.query is called, and no matter what part of the graph users are attached, it’ll exclude the deleted ones.

That’s just one example, but in general bigger/older apps tend to struggle with data loading growing pains.

As feedback - a few more introductory paragraphs about:

• what part of the “domain querying” problem domain this library is intended to solve
• what alternatives (if any) are available, and why they might not be quite suitable for this
• what use cases this has

would be very helpful. I think it certainly covers a gap in most libraries, especially in backends with complicated ephemeral and internal state (a lot of ORM systems assume a backing database), but a couple of paragraphs would market that a lot better.