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

[greemo]

Description

Hi Guys,

There still seems to be an issue with Scalar support. Specifically with passing scalars through to GraphQL backends.

When a GraphQL backend has an schema (schema.graphql) such as:

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

And I add it to Wundergraph as a GraphQL api using the following in wundergraph.config.ts:

const scalars = ["URL", "UUID", "BigInt", "JSON", "Timestamp", "Date", "DateTime", "UCUM"];
const schemaString = readFileSync('schema.graphql', 'utf-8');
const api = introspect.graphql({
    url: "http://localhost:8001",
    loadSchemaFromString: schemaString,
    customJSONScalars: scalars,
    headers: builder => builder.addClientRequestHeader("Authorization","Authorization")
});

And define an operation in Wundergraph as follows:

mutation setValue($id: Int!, $value: JSON!){
  updated: setValue(id:$id, value: $value)
}

Then I call it from the JSON-RPC interface, I see the following in the log:

--- ClientRequest start ---

POST /operations/setValue HTTP/1.1
Host: 127.0.0.1:9991
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 25
Dnt: 1
Origin: http://127.0.0.1:9991
Pragma: no-cache
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0

{
"id": 80, "value": 13
}



--- ClientRequest end ---



--- DebugTransport ---

Request:

POST / HTTP/1.1
Host: 127.0.0.1:8001
Accept: application/json
Content-Type: application/json
X-Request-Id: 339497e1-84df-1728-b5b1-9a60f6dffa95

{"variables":{"id":80,"value":"13"},"query":"mutation($id: Int!, $value: JSON!){updated: setValue(id: $id, value: $value)}"}

Duration: 32905720 ms

Response:

HTTP/1.1 200 OK
Content-Length: 198
Content-Type: application/json
Date: Wed, 11 Oct 2023 23:42:33 GMT
Server: uvicorn

{"data":{"updated":null},"errors":[{"message":"Received String","locations":[{"line":1,"column":36}],"path":["updated"],"extensions":{"exception":null}}]}

--- DebugTransport

As you can see, I pass value as an Int to the JSON-RPC interface, but when it is passed to my backend from Wundergraph, it is converted to a string.

This should not be happening. Wundergraph should not be converting JSON inputs to strings to pass to the backends.

The desired outcome is the input entered at the Wundergraph JSON-RPC interface is passed as-is to the GraphQL backend.

Please also test with the GET requests - First with a URL decode on the parameters.

Reproduction

Please see above.

Using "@wundergraph/sdk": "^0.179.1" and node v18.12.1 (npm v9.6.2)

[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?

[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]

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.

[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]

Hey, this is still a valid issue. Please don't close