Just use SQL? A much better language with saner semantics overall.
My first and last impression from GraphQL were that whoever wrote it hadn't had a chance to work with other query languages. A lot of the problems OP mentioned were quite on the surface. Had you ever used ORM, you'd be very intimately familiar with N+1 problem. Had you ever encountered SELinux, you'd be painstakingly familiar with authorization problems. Had you ever worked with XML (especially schemas), you'd be aware of parsing problems created by exploiting recursive properties of the grammar.
To me, GraphQL feels like a project by someone who is very enthusiastic, but lacks experience. If you need more examples of the same: the Terraform configuration language (not sure what it's called), Neo4j query language (I think it's called Cypher), libconfuse, Protobuf, and many, many more... unfortunately.
Oh but there are some hilarious and obvious problems with Protobuf that are a sure tell of the author being a first-timer.
For example, messages inside messages and messages in other "packages" can, accidentally be named the same, and then the author of such a definition will be spending a lot of efforts debugging such code because, without telling anyone, Protobuf parser (the one written by Google, other implementations behave differently) will prefer the one inside another message to the one inside another package.
To make this more obvious, suppose Protobuf had "package" separator, let it be ":". Then, you could define messages a.b:c and a:b.c. Then, there's no ambiguity. However, since there's none, and physically, the message a.b:c lives in b.pb file and a:b.c lives in a.pb file...
Another hilarious aspect is that fields inside messages are allowed to repeat (in the wire format). And the last one wins! So, using this easy foot-gun, Protobuf made streaming impossible.
Another tell is that Protobuf didn't have a formal grammar until much, much later. And once it was written, it was never tested on the real parser. I submitted a handful of tickets against that grammar because it was ridiculously bad. Simple and very common stuff like strings, that requires a little bit of sophistication (because of quotes and escape characters) was broken in the way indicative of someone doing it for the first time (and not even trying to test). The kind of screwups I saw my classmates do in our automata theory class.
It's wild and weird how such a poorly conceived "invention" gets enormous amount of attention and use (probably because of the company behind it).
My first and last impression from GraphQL were that whoever wrote it hadn't had a chance to work with other query languages. A lot of the problems OP mentioned were quite on the surface. Had you ever used ORM, you'd be very intimately familiar with N+1 problem. Had you ever encountered SELinux, you'd be painstakingly familiar with authorization problems. Had you ever worked with XML (especially schemas), you'd be aware of parsing problems created by exploiting recursive properties of the grammar.
To me, GraphQL feels like a project by someone who is very enthusiastic, but lacks experience. If you need more examples of the same: the Terraform configuration language (not sure what it's called), Neo4j query language (I think it's called Cypher), libconfuse, Protobuf, and many, many more... unfortunately.