Why not have the query in JSON? Now you need a new parser. EDIT: Thanks for all ...

colinramsay · on July 2, 2015

There are certain things that are a bit more elegant if you can have a custom query language. One example:

        query UseFragment {
          luke: human(id: "1000") {
            ...HumanFragment
          }
          leia: human(id: "1003") {
            ...HumanFragment
          }
        }
        fragment HumanFragment on Human {
          name
          homePlanet
        }

You could definitely have some JSON to represent this but it might turn out to be more trouble than it's worth...

agrothberg · on July 7, 2015

What about YAML?

gniquil · on July 3, 2015

It's sad that you capitulated. I agree with your original point more. Is this thing really flexible, composable, and implementable? How long do we have to wait for people to provide solid implementations on top of all the popular programming language and database backends? Feels like SQL all over again. Someone will be writing layers on top of this in javascript in the frontend and ruby/python/javascript/etc. in the backend. Then we are in another ORM hell. (Perhaps I am being too pessimistic here, it could very well be great, but I have some serious reservations...)

andreasklinger · on July 2, 2015

the query contains by far more logic than should be put into json

you could map it to json - but technically you could map everything to json - doesnt mean you decrease complexity

the parser is the lowest problem of parsing and optimizing those queries i'd assume

monk_e_boy · on July 2, 2015

Readability I guess. The new syntax looks pretty good to me. A little heavy on the (( and )) but very obvious as to what is being asked.

voyou · on July 2, 2015

I wonder how important readability is in this case, though. How likely is it that this language will be written (or read) directly by people, rather than generated and consumed by programs? The potential bugs in generators and parsers (think SQL injection) seem like a real cost, which I would have thought would outweigh the benefit of improved readability.

leebyron · on July 2, 2015

GraphQL is definitely designed to be written by developers, not by tools. We have a feature called query variables that provides the same strong typing to input values for queries that need to fetch different data dynamically.

seivan · on July 2, 2015

I'm guessing you might want some 'small' parts of logic, like the unary operation. Guessing!

dandellion · on July 4, 2015

MongoDB did JSON queries. After having useed it I don't think it's a good idea at all.

jackmoore · on July 2, 2015

I believe Netflix's Falcor, which seems very similar to Relay, uses JSON.

kolev · on July 2, 2015

Where in the world is Falcor? We keep hearing about it, we saw the presentation, but this is all we've got and it's nothing: https://github.com/michaelbpaulson/Falcor

nutate · on July 2, 2015

I had made a comment on twitter that the ref: concept basically throws json off the indecidability cliff in terms of parsing. They opened an issue for it apparently, but you can see the graphql rfc has specific anti-cycle checks, which is super important.