Query & document limits
Cap selection depth, aliases, and root fields before resolvers run - complementing HTTP body limits and timeouts.
Use these limits when public clients can submit arbitrary documents. They protect the parser and executor from large shapes, but they do not replace authentication, rate limiting, or an operation allowlist.
GraphQL’s flexibility means a single POST may reference thousands of selections or fan out combinatorially (alias bombs, extremely deep fragments). grx rejects abusive shapes during parse/validation via executor options usually driven from server.New(server.Config{…}):
| Field | What it limits |
|---|---|
MaxSelectionCount | Total field selections in the operation |
MaxAliasCount | Number of aliased fields |
MaxRootFieldCount | Parallel top-level selections |
MaxSelectionDepth / grx.WithMaxSelectionDepth | Nested selection depth |
Not a full “cost engine”
Counters are cheap guard rails, not GraphQL cost analysis (no per-type weights). Pair with gateway rate limits, WithRequestTimeout, and APQ/trusted documents for public APIs.
HTTP payload caps and operational walkthrough: Limits; masking and gateway hooks: Security. Document-shape mechanics: Execution pipeline.
Example
package main
import (
"log"
"example.com/hello-grx/graph"
"github.com/grx-gql/grx/server"
)
func main() {
srv, err := server.New(server.Config{
Schema: graph.Schema(),
MaxSelectionDepth: 16,
MaxSelectionCount: 750,
MaxAliasCount: 120,
MaxRootFieldCount: 8,
})
if err != nil {
log.Fatal(err)
}
_ = srv
}Related
- Persisted queries - shrinking unknown document surface
Last updated on