Clojurians Log v2

Hi folks, I am just getting used to Lacinia and GraphQL, with a basic question that I hope you can help me with. I refer to the critique here: https://github.com/vvvvalvalval/d2q#lacinia-and-graphql

They say "queries are difficult to compose and transform, which greatly hurts the programmability of GraphQL".

I wasn't able to figure out how to compose queries at all, actually, and I wonder if someone could give me some pointers.

What I understand from the documentation of Lacinia is that you can give it a list of queries, but there's no guarantee about execution order.

So, the specific use case I have in mind: I want to do something akin to a SELECT * FROM tablename_ -- in fact, that's basically how the query is implemented.

But then I would like to do further processing of the id field that returned from that query.

The docs say that mutations do have a guaranteed execution order, but it seems to me that these are usually used to update the database, rather than to update the results of a previous query.

I wonder, is this ever done? Using a mutation to update a query that has just run, I mean. So, in my case I could take the id field and expand the query results (e.g., by testing whether that id has other properties).

The alternative is to change the SELECT statement in the database backend, but this seems like a fairly hacky solution.

graphql is very much not sql, where as sql has a sort of transitive closure where a sql query can kind of be the input to another sql query, that isn't really the way graphql is structured, and graphql is really a facade that ties together different bits into a uniform model for clients, so it is entirely possible that yeah, based on slightly different queries from clients you might change which sql query you run, or maybe even change which datastore you consult

graphql mutations are analogous to like an update, insert, or delete in sql, where as queries are like a select, so talking about applying mutations to results of queries makes about as much sense as talking about applying an update to the result of a select (none)

if you look at something like https://www.howtographql.com/graphql-js/8-filtering-pagination-and-sorting/ the way it filters things is by passing the filter into the resolver, and if a filter is passed in the resolver applies it when resolving

re: ordering, resolvers are run from the root to the leaves, so the resolvers higher in the graph will run first and can get information in bulk and pass it down to the leaves

https://lacinia.readthedocs.io/en/latest/resolve/selections.html#previewing-selections