In GraphQL the query for the example you gave could look like this
```gql
query {
user {
things {
owner {
id
}
}
}
}
```
Now if your developers are intentionally creating infinitely deep queries, then you'd solve this the same way you'd solve an infinite loop in your code today. An issue you would catch during development or CI/CD. This can be easy to catch using a linter or during review.
```gql
query {
user {
things {
owner {
things {
owner {
things { } # etc
}
}
}
}
}
}
```
In addition you could introduce CI tools to enforce your devs stop writing such complex queries. Also see the @skip and @include directives that can further be used to control what data is queried. In practice, however, this isn't something that comes up too much. In cases where I have seen this happen, it's usually because a developer is trying to reuse fragments without considering what data they are querying, and whether they should be reusing those fragments.
In practice this is an issue for any publicly exposed GraphQL API.
That's why the only solutions to the issue are to:
- either deserialize and deep inspect the query to try and figure out if it's too complex
- or to only expose persisted queries, turning it into a bad replica of JSON RPC.
Can you explain this more? How can you avoid infinite graphs? If I have User {things: Thing[]} and Thing {owner: User}, you have to deal with this issue.