Hacker News Reader

Comment by dgb23 | Hacker News Reader

One of the major issues I have with GraphQL from the get go is that it introduces it's own syntax instead of using a commonly understood and established _data_ format like JSON or similar.

Same problem with Prisma Model definitions and other such things.

Please, if you make a new thing and it fits neatly into a data format, use a data format! Let me use all of those well established libraries, schema definitions and programming concepts in order to generate, parse and make sense of your thing. Let me seamlessly write your language with the data structures I already know in my language if that's possible.

Don't make it pretty, make it usable.

View on HN

What do you mean? Both GraphQL queries and results are JSON. The query expression is just a json string. Are you referring to the schema language?

From https://graphql.org/learn/queries/

This isn't even close to valid json:

  {
    empireHero: hero(episode: EMPIRE) {
      name
    }
    jediHero: hero(episode: JEDI) {
      name
    }
  }

and I strongly agree with GP because those arguments <https://graphql.org/learn/schema/#arguments> can get to be insaneo with anything other than simplistic "episode: EMPIRE"; I regrettably can't link directly to it but https://docs.github.com/en/graphql/reference/objects#:~:text... shows that stuff can start to be more than the interior field selection, to say nothing of schemas that define complex typed arguments e.g.

  type Starship {
    id: ID!
    name: String!
  }
  type CaptainQuery {
    captains(starshipFilter: [Starship!]): [Starship]
  }

  # leading to
  {
    captains(starshipFilter: [{name: "Alpha"},{id: "cafebabe"}]) { id }
  }

which I recognize is most often fixed via variables but when the hello-world examples call it out, something has gone awry https://docs.github.com/en/graphql/guides/forming-calls-with...

That has some json-ish embedded inside it, but the query itself still isn't json.

And even the embedded part isn't valid json without quoting the keys.

But if you write the query to use variables, the variables are json.

JSON is great (though not perfect) as an interchange format, but it’s decidedly not a query language.

i agree with this. Writing queries is the most annoying part of graphql

I can’t imagine how annoying it would be if we had to write queries in JSON!

writing queries is stupid easy if you use a tool like GraphIQL especially with the explorer.

Even better, all of this stuff is integrated into language servers with typechecking based on your gql schema, auto completion, and all the minting checks we’ve come to expect. Is a field nullable but you’re only handling to non-nullable case? The editor catches it.

I think this is a classic case of anecdotes not adding up to data.

It's not that it's "hard" as much as it's annoying. When every react component has its own fragment, writing so many graphql fragments gets annoying. Going to graphiql for each fragment is annoying. Figuring out what fragments need to be spread on a query can be annoying. It's just more stuff that you have to keep in your head.

With that said I still like using relay on my random react-native side projects.

I just reread my post. I meant to say that GraphQL requests, not queries, are JSON.

Of course the query itself is not json, why should it be? It describes the shape of a json object, and queries are generally pretty static. But the request to the server is json, the request variables are json, the result is json, and all the json tooling can be used in the responses in our clients.

Honestly, one of the reasons I like GraphQL is the fact that underlying it all is just JSON.

They are referring to the schema language

Reply on news.ycombinator.com