Re:GraphQL Working Draft
by colinramsay on Thursday July 02, 2015 @07:56AM
(#9818253)
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...
Re:GraphQL Working Draft
by agrothberg on Tuesday July 07, 2015 @07:11PM
(#9848757)
What about YAML?
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...)
Re:GraphQL Working Draft
by andreasklinger on Thursday July 02, 2015 @07:58AM
(#9818260)
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
Re:GraphQL Working Draft
by monk_e_boy on Thursday July 02, 2015 @07:59AM
(#9818262)
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.
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.
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.
I'm guessing you might want some 'small' parts of logic, like the unary operation. Guessing!
Re:GraphQL Working Draft
by dandellion on Saturday July 04, 2015 @05:24AM
(#9829708)
MongoDB did JSON queries. After having useed it I don't think it's a good idea at all.
I believe Netflix's Falcor, which seems very similar to Relay, uses JSON.
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
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.
EDIT: Thanks for all the replies, all of them very good points, and clearly show that JSON is not the most elegant option for a complex DSL.