[philplckthun]

I'm honestly not sure whether there's really a good excuse to invent a format that's immediately incompatible with all GraphQL tooling out there, which would need to be converted. After all, debugging and logging tools could still display these.

It also conveniently leaves out automatic persisted queries which would replace queries with hashes, or regular persisted queries, where we'd have a limited set of allowed queries on the server-side that it accepts.

I think ultimately when I think of sending GET requests for GraphQL, I'm immediately more worried about the URL length limit. The risk being that at some point in the future we may run over this limit and get into a lot of unexpected trouble.

Also, this article assumes that you can only stringify GraphQL a single way, with spaces. However a not as commonly known detail in the spec is that any commas are treated the same as whitespaces. Hence, this is a valid query:

  {item(id:4){id,name,author(id:4){id,name}}

Which isn't far off from reading a complex query string IMO, works with any existing GraphQL API via GET if the API already accepts GET requests, and isn't a special format that'll need to be learned supporting the full syntax.