How do GraphQL based systems solve the problem of underlying database thrashing, hot shards, ballooning inner joins, and other standard database issues? What prevents a client from writing some adversarial-level cursed query that causes massive internal state buildup?

I’m not a database neckbeard but I’ve always been confused how GraphQL doesn’t require throwing all systems knowledge about databases out the window

▲

2 days ago | parent | next [-]

[deleted]

▲

spooneybarger 2 days ago | parent | prev [-]

Most servers implement a heuristic for "query cost/complexity" with a configurable max. At the time the query is parsed, its cost is determined based on the heuristic and if it is over the max, the query is rejected.

▲

lll-o-lll 2 days ago | parent [-]

Which would be fine for internal facing, but it doesn’t sound like it would be enough in an adversarial context?

	▲	spooneybarger a day ago \| parent [-]
		There are a lot of public facing graphql servers that use it without issue other than frustrating users of non adversarial but complex requirements. The problem is that it is generally on a per request basis. An adversary is going to utilize more than a single query. It mostly protects against well intentioned folks. Other forms of protection such as rate limiting are needed for threat models that involve an adversary. The same problems exist with REST but there it is easier as you can know query complexity ahead of time at end points. GraphQL has to have something to account for the unknown query complexity, thus the additional heuristics.