Designing a URL-based query syntax for GraphQL

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.

PQL looks like a cracked out parrot ran across my keyboard:

    /?
    query=
      posts(
        ids: [1, 1499, 1178],
        order: $order
      )@posts.
        id|
        date(format: d/m/Y)|
        title<
          skip(if: false)
        >|
        --props&
    order=title|ASC&
    props=
      url|
      author.
        name|
        url

All-in-all this seems like a very roundabout way to achieve HTTP-level caching for queries.

Reasoning about the query as a literal string instead of _data_ is where I think this went off the rails. I probably would have just added middleware to allow for base64 encoded queries and then gone that route. A query can get deterministically hashed into a string of chars.

Might be me but I don't see the alternative as readable either. There's also a bunch of knowledge specific to that format which makes it almost tribal if you've not got a reference handy.

Seems like an unnecessary layer of abstraction to me. If I'm in a webbrowser anyway, it's much easier to open the console, write decodeURIComponent(`<your_encoded_query_here>`) and look at the decoded query rather than having to translate PQL to GraphQL syntax in my head, especially since the GraphQL will be a nicely formatted multi-line string whereas the PQL is single-line.

What is wrong with Odata?

Odata v4 with json payloads is more or less how most would define the payload manually, it has all the benefits of GraphQL (retrieving a tree of objects, selecting required attributes), is fully compatible with Rest (retrieves are GETs, mutations can be POST, PUT, DELETE), has a true query language with filtering, aggregations, expressions, joins, paging, sorting, which are all part of the url so you can cache it like a normal Rest GET, has batches so you can update multiple objects in one transactions, and supports subscriptions so you can receive updates instantaniously...

I could've sworn I've seen something like this before... oh! Oh! XPath[0]!

[0]: https://en.wikipedia.org/wiki/XPath

Ok but https://www.w3.org/TR/rdf-sparql-query/ seems to suffer from the same problems as GraphQL, maybe people don't actually care what the query looks like URL encoded as you generally have tools that tell you actually what the query is.

This is clever! Can anyone help me understand how this lines up with the original value proposition of GraphQL? I was under the impression that the Big Idea behind GraphQL was, amongst other things, client-side caching [1]. I’m probably missing some nuance here, so bear with me: if your GraphQL client is caching properly, then what would this syntax give a developer that a URL query parameter parser couldn’t?

[1] https://graphql.org/learn/caching/

The idea of GraphQL via GET is great, but I'm not sure of the value of optimising for readable URLs. I honestly don't find that syntax much more readable than single-line GraphQL. That's fine though, because honestly who needs to write queries manually in the URL anyway? Everyone is either going to be using a library, or GraphiQL.

Why is having url query params be human readable a requirement?

Non devs do not care one bit about the query params, and devs don't write them by hand so who cares?

Clever, but this solution feels like the space pen to base64's pencil. :)

Now this is a version of graphql i can get behind.

This is absurd.

Transmitting and displaying text in two dimensions has been a solved problem since the teleprinter was invented in the 1920s.

> PQL is a superset of the GraphQL query syntax.

This is so obviously wrong.

I love GraphQL and I loathe how URLs look. This is a neat concept.

This is not necessary

what problem does this solve?