[Issue]: Scalar input fields on GraphQL datasource converted to strings about wundergraph

[greemo]

@Pagebakers thanks again for the time spent responding.

I understand Wundergraph at the moment forwards a JSON string. I understand how to unpack JSON strings, however I'm expecting a raw JSON value as specified by the GraphQL spec whenever scalars are used.

The GraphQL spec allows raw JSON values and by doing stringification, you make Wundergraph incompatible with all the GraphQL APIs that rely on receiving a raw JSON value.

If your schema is as followed, we have no way of knowing which format you are expecting.

You know the format is JSON. That's all you need. The reason Scalars exist is so formatted JSON can be passed around without intermediates needing to know the format. It is great that users can inform Wundergraph of the structure if the schema of the scalar is known in advance, but often the schema is not known in advance. That's why JSON exists. In this case, Wundergraph should not need to know what format is expected, just pass the JSON directly through.

If a field is a scalar, and not defined in the replaceCustomScalarTypeFields entry, just pass the value through.

[Pagebakers]

Thanks for opening this issue @greemo

JSON type fields are always parsed into a string, so 13 would become "13", this is the default behavior of WG. On your server "13" would be decoded (eg JSON.parse("13") again to 13.

You can make the types more specific by using replaceCustomScalarTypeFields
https://docs.wundergraph.com/docs/guides/extend-json-fields-with-more-specific-types#step-2-extending-the-graph-ql-schema-with-our-custom-type

Does this answer your question?

[greemo]

Hi @Pagebakers, thanks for the quick response.

Why is parsing JSON into strings the default behaviour? This is effectively changing the interface of the backing service, meaning scalars cannot be used by any graphql server behind wundergraph.

This severely limits the functionality of graphql.

Is there a way to disable this behaviour?

[Pagebakers]

If your schema is as followed, we have no way of knowing which format you are expecting.

With customJSONScalars the value input now accepts any valid JSON encodable value, that is then encoded into a JSON string. eg JSON.stringify(13) becomes "13".

type Mutation {
  setValue (id: Int!, value: JSON!): Boolean
}

In your server your custom JSON scalar would then parse the JSON value.

Assuming it runs on Node.js:
JSON.parse("13") becomes 13.

And it should all work as expected.

[brampurnot]

Interesting. I'm having the same issue. When I define it as a JSON array (i.e. [JSON]), then the entire object is stringified:
["{"key":"realm","value":"something"}","{"key":"$filter","value":"(UniqueName eq 'CR3640')"}"]

Is this expected behavior too?

[Pagebakers]

I'm not sure what you mean with JSON string and raw JSON value, those seem to be the same things right?

WunderGraph passing the JSON scalar value back to the GraphQL API as a JSON string (this is RAW JSON) which seems correct to me?

Coming back to the number example. 13 is not a valid JSON value but "13" is.

[greemo]

Hi @Pagebakers,

By JSON String, I mean something surrounded by " characters. By raw JSON values, I mean anything that is valid JSON.
Raw JSON values are obviously strings at the HTTP level as a HTTP string does not require a " character.

Maybe an example is helpful:

13 is valid json, and is a JSON integer, not a JSON string. https://www.json.org/json-en.html, https://jsonlint.com/
"13" is also valid JSON, but is a JSON string. It is a stringified JSON integer.
{"foo": 3} is valid JSON, and is a JSON object
"{\"foo\": 3}" is valid JSON, it is a JSON string. It is not a JSON object. It is a stringified JSON object.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[greemo]

Hi @Pagebakers, did my last comment help with understanding the problem?

[greemo]

Hi @Pagebakers, @StarpTech hope you guys had a great vacation over new year. Any chance of looking over this issue?

If there's any more info I can help with, please let me know.