I don't know, I've seen lots of REST APIs that have similar levels of query configurability (albeit without the predictable syntax of GraphQL). It's certainly not uncommon for REST APIs to support params for sorting, filtering, and including related entities (i.e. joining), at which point you could just as easily open yourself up to dangerous queries as you could with GraphQL.
Most definitely and I allude to them in my initial post because it's basically the same problem. Can't get rid of all parameters in all cases of course. Of the common configurability options I see in REST APIs, the ones that affect queries in the most complicated way is the customizable inclusion of extra relational properties.
Re:Why use GraphQL, good and bad reasons
by tomnipotent on Friday August 24, 2018 @03:38PM
(#17837325)
> Rarely good enough
That's baloney. GraphQL can have just as locked down code paths as any non-GraphQL API. Facebook does exactly this.
I never said they couldn't. What's baloney is pretending FB's approach towards GraphQL is replicated by all. Anyone that's seen the tech deployed in multiple places (and equivalent systems) has seen the cavalier attitude with which data can be accessed with seemingly infinite unique combinations. And it's especially true if you revisit them after some time to see they often grow, but rarely are paths or properties deleted. Sometimes it's due to API compat guarantees, but often it's due to the ridiculous divorce between actual client side usage and expected server side usage.
That you can do it right is not at issue, it's whether you do, and over time IME it's unaudited data proliferation and even when data is controlled, often unaudited permutations of all the possible queries that can be built.
Rarely good enough and in general a dangerous mindset that just adding layers around is an acceptable solution to essentially giving the world a query builder (internal use only is different of course).
> Security doesn’t seem like a problem unique to GraphQL
It's about surface area of permutations as much as the data. Sure you can auth property paths, but many GraphQL setups can be gamed by malicious callers to strain systems in ways you never expected those client side devs to do when you gave it to them. If the only reason for this flexibility is because they can't be bothered to do a bit of server side tailoring, you have a dev fragmentation problem and a vertical integration problem that will cause security concerns one day anyways.