I tried a different strategy early in my teaching and emphasized evaluation: How will you validate the success of your interface? Students were often flustered. They would eventually begin to define their research instrument based on “things found.” If they caught on, validation might include supporting the analyst in testing hypotheses, finding significant differences, outliers, patterns, etc. If they really caught on they’d start to articulate what decisions are enabled based on what is found (pattern A means buy a stock, pattern B means sell it). Unfortunately, if they didn’t catch on (a common occurrence), they’d tell me that they would evaluate their “exploratory tool” based on analyst “insights.” And while we, in research and practice, might have very specific definitions for insight, the students did not. “Insight” was as vague as “explore.”
So that’s why variables exist — to help us compose our GraphQL queries ahead-of-time as often as possible. I hope this gives some more insight into the thoughtfulness behind GraphQL and how it’s been designed to address real engineering needs (at scale! as they say).