Yep. It is not trivial to make it into a pseudo-SQL language, like Hasura did.
Funny enough, see this assumption frustrating a lot of people who try to implement GraphQL APIs like this.
And even if you do turn it into a pseudo-SQL, there's still plenty of control. Libraries allow you to restrict depth, restrict number of backend queries, have a cost function, etc.
...and that's exactly the problem! Without a lot of hardening, I (a hostile client) can suck down any part of the database you make available. With just a few calls.
GraphQL is too powerful and too flexible to offer to an untrusted party.
This is a silly argument and sounds like a hot take from someone who's never used this. You could say the same about REST or whatever. It has nothing to do with "the database".
You sound like someone that's never had an adversarial client. I spent years reverse engineering other companies' web APIs. I'm also responsible for a system that processes 11 figures of financial transactions, part of which (for now) is an incredibly annoying GraphQL API that gets abused regularly.
REST calls are fairly narrowly tailored, return specific information, and it's generally easy to notice when someone is abusing them. "More like RPC".
Your naive GraphQL API, on the other hand, will let me query large chunks of your database at a time. Take a look at Shopify's GraphQL API to see the measures you need to take to harden an API; rate limits defined by the number of nodes returned, convoluted structures to handle cursoring.
GraphQL is the kind of thing that appeals to frontend folks because they can rebalance logic towards the frontend and away from the backend. It's generally a bad idea.
