In practice there are not two queries. Dgraph in the Var block collects the required UIDs and treats them in the next block. I think this logical separation is good for keeping the queries simpler. If we were to add different logics to the language this would eventually make GraphQL± impractical.
If you try to always use the Var block, you get used to it.
There are plans to slightly modify the language and make it strongly typed - but I do not know about the time range for work on it or any other detail.
I don’t know how to say it right, but I think there is a flaw in the concept in your thread question.
Look, by design it would not be possible to sort Parent by an Alias (or not) from a Child. A value that will still be produced/processed and belongs to a Child is not expected/predicted to classify the Parents nodes.
Having this in mind, you need to go through a Var block to be able sorting as you want. By a child value.
I think could add a feature sorting with Count Index at root (Count index is diff from Count uid in the enclosing block). Fill up an issue for this. This could be a real solution to your case. But keep in mind that Count Indexing costs a little.
count(predicate) counts how many
predicate edges lead out of a node.