Consider using data structures rather than a grammar to define the language about graphql-spec HOT 4 CLOSED

@kylewilt just out of curiosity, are you talking about implementing queries like in mongodb or elasticsearch, e.g.

db.inventory.find(
   {
     type: 'food',
     $or: [ { qty: { $gt: 100 } }, { price: { $lt: 9.95 } } ]
   }
)

instead of using a SQL-like syntax?

from graphql-spec.

Yes that's the basic idea, of course that's a language specific implementation in your example. Ideally GraphQL would be defined in terms of pure conceptual data structures like maps, arrays/vectors, sets, etc with basic rules/expectations so that any language can fairly easily implement GraphQL using its native data structures rather than the string concatenation/parsing noise.

You can always define a standard textual representation over top of data structures but going the other direction is unpleasant and often harder to do because the grammars can start to deviate from something that is sensibly convertible to standard data structures in a consistent way. I can see a future world of "GraphQL Mappers" that turn your nice friendly language specific data structures that you normally prefer to work with into GraphQL text which is not really the world I'd prefer personally.

Having a non textual interface as the spec will simplify testing scenarios since you don't have to test for structured strings and enable faster throughput since you can pick more terse binary transport protocols or even direct function calls.

from graphql-spec.

We did in fact consider this and decided that the legibility of the query language was one of the critical factors we wanted to include. We were not able to come up with a JSON-specific representation that both covered all the cases and was easy to write and read. If someone wants to produce a library which defines such a thing and converts to and from GraphQL, I think that would be a perfectly good community project, but for now GraphQL will continue to maintain its language.

from graphql-spec.

Another important consideration is that GraphQL is defined to be a common request language regardless of frontend or backend languages involved. Since different languages have different representations of data structures, we still must agree upon a serialization format which can represent these concepts across most environments. JSON is probably the go-to for this sort of thing, but JSON feels pretty limiting for this task.

EDN is an interesting alternative because it is far more flexible than JSON, and datascript is a pretty great example of how EDN can be used to define this kind of macro language / datastructure. Taking a dependency on EDN is probably not the right decision for GraphQL, but we would encourage experimentation with EDN-macro style GraphQL-like systems.

from graphql-spec.