4 ms·

What i don't like about Graphql is that it enable stringly type query. Why not enforcing JSON instead ? Stringly type is too hard to be manipulated.

alexchamberlain 7y ago
Can you give an example of what you mean?
- revskill 7y ago
  I mean, instead of query { user { id name } } why not query: { user: { id: true, name: true, } }
  - strken 7y ago
    Generally you'd use a library with much stricter conventions than JSON to generate and parse GraphQL queries, rather than writing them as a string. If you're using JS/ES/TS, you can even configure a linter[0] to validate your queries against a schema as you're writing them. Insofar as JSON is a type system, it's a weaker one than GraphQL, and would be a lot more verbose. Consider the query query(id: Int, hasUser: Boolean) { @include(if: $hasUser) user(id: $id) { name } } It would be possible to represent this in JSON, but it would be a lot less elegant. { "query": { "args": {"id": "int", "hasUser": "boolean"}, "fields": { "user": { "args": {"id": "$id"}, "fields": {"name": true}, "includeIf": "$hasUser" } } } } The JSON still depends on stringly-typed values like "$hasUser", but it's much harder to read and has many more unnecessary characters. EDIT: if you want to manipulate GraphQL queries, you need to parse them[1] and then look at the AST. This is not very well documented, so the best way of doing it is by experimenting with the values you've got, and then verifying your approach against graphql-js. [0] https://github.com/apollographql/eslint-plugin-graphql https://github.com/apollographql/eslint-plugin-graphql [1] https://github.com/apollographql/graphql-tag https://github.com/apollographql/graphql-tag
tuyiown 7y ago
> Stringly type is too hard to be manipulated. With param and fragments, the json would be too verbose, so you'd end up by always building your queries programmatically, so sharing queries between GraphQL implementations and/or runtimes/languages would be harder. GraphQL language for queries and schema adds a layer that describe what your runtime and/or compile time has to conform with, which is incredibly helpful for stacks with heterogeneous environment. In the end, you can always parse and generate those full text documents and manipulate them programmatically, as much as you want (just be cautious with perfs). So the apparent fragility has many ways to be addressed, with a huge advantage of having common ground on all stacks.
- revskill 7y ago
  With JSON, you have many benefit, such as syntax error for JSON. It's impossible with stringly type. With dynamically generation of query, JSON parsing is easier than stringly type. You don't need a library like graphql-tag to do that. Instead of posting a string body request, you post a JSON request, which is the standard way for long time. In general, stringly type graphql query is not a fine choice to me.
underwater 7y ago
I hate to break it to you, but JSON is a string too. i.e. There is no such thing as a "JSON value" in JavaScript, just a method that will convert a subset of JavaScript primitives to a JSON string encoding. GraphQL is a well-defined syntax that can be validated by both client and server. An invalid query can be rejected with a syntax error. Yes, it is harder to dynamically construct a GraphQL query on the client, but you shouldn't do that anyway. The language has directives and variables that can introduce dynamic elements.
- revskill 7y ago
  JSON here is used as a structured format, with clear specification. Graphql query also has specification, and you can encode it with JSON format, too. WHy not ?
  - underwater 7y ago
    What do you mean by structured? How is GraphQL structured Would you consider something like PHP's serialize() function to be structured? serialize(array('1' => 'elem 1', '2'=> 'elem 2', '3'=> 'elem 3')); // a:3:{i:1;s:6:"elem 1";i:2;s:6:"elem 2";i:3;s:6:"elem 3";} There are a lot of advantages to creating a custom syntax. In your example what does `query: { user: { id: 1, name: "true", } }` yield? How do you represent fragments? How do you represent variables and directives? You could implement conventions like `$ref`s in JSON schema, but then you've ended up creating another custom syntax... just this time it's piggy backing on JSON instead of plain text.
  - baq 7y ago
    parse the query, emit ast as json, done. to me one of the important points of graphql is that it isn't json.

alexchamberlain 7y ago

Can you give an example of what you mean?

revskill 7y ago
I mean, instead of query { user { id name } } why not query: { user: { id: true, name: true, } }
- strken 7y ago
  Generally you'd use a library with much stricter conventions than JSON to generate and parse GraphQL queries, rather than writing them as a string. If you're using JS/ES/TS, you can even configure a linter[0] to validate your queries against a schema as you're writing them. Insofar as JSON is a type system, it's a weaker one than GraphQL, and would be a lot more verbose. Consider the query query(id: Int, hasUser: Boolean) { @include(if: $hasUser) user(id: $id) { name } } It would be possible to represent this in JSON, but it would be a lot less elegant. { "query": { "args": {"id": "int", "hasUser": "boolean"}, "fields": { "user": { "args": {"id": "$id"}, "fields": {"name": true}, "includeIf": "$hasUser" } } } } The JSON still depends on stringly-typed values like "$hasUser", but it's much harder to read and has many more unnecessary characters. EDIT: if you want to manipulate GraphQL queries, you need to parse them[1] and then look at the AST. This is not very well documented, so the best way of doing it is by experimenting with the values you've got, and then verifying your approach against graphql-js. [0] https://github.com/apollographql/eslint-plugin-graphql https://github.com/apollographql/eslint-plugin-graphql [1] https://github.com/apollographql/graphql-tag https://github.com/apollographql/graphql-tag

tuyiown 7y ago

> Stringly type is too hard to be manipulated. With param and fragments, the json would be too verbose, so you'd end up by always building your queries programmatically, so sharing queries between GraphQL implementations and/or runtimes/languages would be harder. GraphQL language for queries and schema adds a layer that describe what your runtime and/or compile time has to conform with, which is incredibly helpful for stacks with heterogeneous environment. In the end, you can always parse and generate those full text documents and manipulate them programmatically, as much as you want (just be cautious with perfs). So the apparent fragility has many ways to be addressed, with a huge advantage of having common ground on all stacks.

revskill 7y ago
With JSON, you have many benefit, such as syntax error for JSON. It's impossible with stringly type. With dynamically generation of query, JSON parsing is easier than stringly type. You don't need a library like graphql-tag to do that. Instead of posting a string body request, you post a JSON request, which is the standard way for long time. In general, stringly type graphql query is not a fine choice to me.

underwater 7y ago

I hate to break it to you, but JSON is a string too. i.e. There is no such thing as a "JSON value" in JavaScript, just a method that will convert a subset of JavaScript primitives to a JSON string encoding. GraphQL is a well-defined syntax that can be validated by both client and server. An invalid query can be rejected with a syntax error. Yes, it is harder to dynamically construct a GraphQL query on the client, but you shouldn't do that anyway. The language has directives and variables that can introduce dynamic elements.

revskill 7y ago
JSON here is used as a structured format, with clear specification. Graphql query also has specification, and you can encode it with JSON format, too. WHy not ?
- underwater 7y ago
  What do you mean by structured? How is GraphQL structured Would you consider something like PHP's serialize() function to be structured? serialize(array('1' => 'elem 1', '2'=> 'elem 2', '3'=> 'elem 3')); // a:3:{i:1;s:6:"elem 1";i:2;s:6:"elem 2";i:3;s:6:"elem 3";} There are a lot of advantages to creating a custom syntax. In your example what does `query: { user: { id: 1, name: "true", } }` yield? How do you represent fragments? How do you represent variables and directives? You could implement conventions like `$ref`s in JSON schema, but then you've ended up creating another custom syntax... just this time it's piggy backing on JSON instead of plain text.
- baq 7y ago
  parse the query, emit ast as json, done. to me one of the important points of graphql is that it isn't json.