GraphQL Query Builder's Type Inference — How Does It Guess From a Name Alone?
When you write a GraphQL query, you have to declare a type for every variable, like $userId: ID!. Yet if you type just $userId into the GraphQL Query Builder, it automatically appends ID! for you. It never queried a server schema — so how did it know the type? The answer is: it didn't. What's actually happening is regex matching that guesses purely from the spelling pattern of the variable name. Here's a code-level breakdown of how that works, and where it breaks.
1. Normally, Introspection Is How You'd Know the Type
GraphQL servers typically expose a schema introspection feature. Send built-in meta-queries like __schema or __type to the server, and it returns the full definition of every available type, field, and argument as JSON. This is exactly why tools like GraphQL Playground or Apollo Studio can offer autocomplete — they've already fetched that introspection data ahead of time. In principle, a type isn't something you "guess" — it's something you "confirm" by asking the server.
2. But This Builder Never Asks the Server
MODOO HUB's GraphQL Query Builder is a static, browser-only tool — it never connects to an actual GraphQL endpoint. With no server and no schema to query, if you type $variableName into an argument value, something still has to fill in the query ($variableName: Type) declaration at the top of the query. The method the tool settled on is: run the argument name (key) through regex patterns and guess a type from its spelling. Here's what the actual inferVarType() function does.
| Check order | Regex condition | Inferred type |
|---|---|---|
| 1 | /id$/i — name ends in "id" | ID! |
| 2 | /^(is|has)[A-Z_]/i or /^(active|enabled|disabled)$/i | Boolean! |
| 3 | /^(count|limit|offset|page|number|num|amount|qty|quantity|year|month|day|age)$/i (full match) | Int! |
| 4 | None of the above match | String! |
The key thing to note: this check runs only on the argument name (key), not the argument value — and even then, only when the value is a variable starting with $. If you just type a literal value like "1" or true, this logic never runs at all.
3. Exactly Where the Misclassifications Happen
Rule 1's /id$/i doesn't mean "the field name ends in the word id" — it matches any word whose last two characters happen to be i and d. So along with "userId," ordinary English words like "paid," "valid," "grid," and "avoid" all pass this condition and get misclassified as ID!. A value that should really be a boolean or a string ends up locked into the wrong type, purely because of a naming-convention pattern.
| Variable name | Why the regex matched | Actual tool output | Intended type |
|---|---|---|---|
| userId | Ends in "id" → rule 1 | ID! | ID! (correct) |
| valid | Last two letters of "valid" are "id" → rule 1 | ID! | Boolean! (mismatch) |
| paid | Last two letters are "id" → rule 1 | ID! | Boolean! (mismatch) |
| isActive | "is" + capital letter → rule 2 | Boolean! | Boolean! (correct) |
| title | Matches no rule → default | String! | String! (correct) |
Rules 2 and 3 are relatively safe by comparison. The Boolean rule is anchored (^) so the is/has prefix must be immediately followed by a capital letter or underscore, and the Int rule requires a full-string match (^...$), so there's no room for a partial-match false positive. The only rule that anchors just the end ($) without also anchoring the start (^) is rule 1 — and that's the one that misfires.
4. What to Do About It in Practice
After using this builder to rough out a query quickly, it's worth developing the habit of eyeballing the variable declarations at the top of the generated query once before you ship it. In particular, if an argument name happens to be a common English word ending in "id" (paid, valid, grid, avoid, solid, etc.), treat the auto-inferred type as unreliable and fix it by hand. If you need the exact type from a real production schema, don't rely on this tool — check the server's introspection result or verify separately with the JSON Schema Validator instead. And if you want to clean up the syntax of the generated query itself, pairing it with the GraphQL Formatter is a good idea.
Frequently Asked Questions
Q. Does this tool actually query a real GraphQL server's schema?
No. It's a fully static, browser-only tool that never connects to any server. The "type" it shows is just a regex guess based on the spelling of the argument name.
Q. Does type inference run on literal values like "1" or true?
No. The inference logic only runs when the argument value is a variable starting with $. Literal values are never subject to inference.
Q. Why do names like "paid" or "valid" get misclassified as ID!?
Because the ID! rule doesn't check "is the name exactly id" — it checks "do the last two characters of the name happen to be i and d." Any English word that coincidentally ends that way triggers it.
Q. Do the Boolean and Int inference rules have the same problem?
Much less so. The Boolean rule only matches when a capital letter or underscore immediately follows the is/has prefix, and the Int rule requires the entire string to match exactly — so the odds of a partial-match false positive are low.
Q. How do I fix a misinferred type?
The generated query textarea isn't read-only — it's editable output you can copy and modify directly. Just change the type string in the variable declaration to whatever you actually need.