Request to add API that returns string responses/errors rather than deserialized results

[sidhants]

This will help in making the library usable with il2cpp/no dynamics/WebGL based use cases including Unity which is a big community. The consumer of the API can perform the deserialized operation on their side as needed with any compatible package.

A small addition to the source code at my end was enough to get the responses to work nicely-
public Task<string> SendQueryAsync(GraphQLRequest request, CancellationToken cancellationToken = default) => this.graphQLHttpHandler.PostAsync(request, cancellationToken);

il2cpp successful results in Unity-

@deinok Please let me know what you think about this? I feel it can be very useful to increase the scope of use. Serialization does not have any issues currently with il2cpp once newton json is configured to turn off dynamics and works out of the box as expected. But deserialization does not work because of how the graphql response class is set up and dependent on dynamics data. Other idea would be to use some generic JsonConstructor in the graphql response class that prevents dynamics usage.
The version I am using is 'GraphQL.Client.2.0.0-alpha.3'.

[rose-a]

@sidhants please check the current API (develop branch), it uses System.Text.Json instead of Json.Net and does not use dynamics anymore.

[sidhants]

@sidhants please check the current API (develop branch), it uses System.Text.Json instead of Json.Net and does not use dynamics anymore.

@rose-a I am going to give it another shot with Unity integration this weekend with the latest dev. Though I have heard System.Text.Json is not compatible with Unity probably due to reflection features not supported on il2cpp/iOS/VR/AR headsets. I will confirm this, otherwise need to think of another solution.

[rose-a]

@sidhants the biggest problem I discovered are the Extensions fields on GraphQLResponse and GraphQLError.

I'm not keen on having to specify 3 types for every request...

[rose-a]

Changed the type of extensions to System.Text.Json.JsonElement in e1c8f3b.

If the issue is just the dynamics this should solve it.

[DamianMehers]

System.Text.Json is also not currently supported by Xamarin iOS (or WatchOS) so returning raw JSON would help there too dotnet/runtime#31326 .. I could deserialize using SimpleJson for example.

[rose-a]

Maybe a dumb question, but how does the serialization work if the serializer is not supported?

Also with websockets this won't be possible, they need to deserialize the response to match the request ID...

How do you do JSON serialization/deserialization on those platforms anyway?

[sidhants]

Maybe a dumb question, but how does the serialization work if the serializer is not supported?

Also with websockets this won't be possible, they need to deserialize the response to match the request ID...

How do you do JSON serialization/deserialization on those platforms anyway?

Well, this is the specific version compatible with Unity (Unity is multi platform to target android/ios/webgl/etc) https://github.com/jilleJr/Newtonsoft.Json-for-Unity.
I had recompiled the repo with it. Serialization worked with this with the previous code and http requests were good, but response deserialization which used a dynamic data field in the graphql response class would make it crash on the device. Thus the raw response was a workable solution.
Also, Unity has its own inbuilt JSON library https://docs.unity3d.com/ScriptReference/JsonUtility.html
SimpleJSON also works as far as I know.

[rose-a]

So I suppose deserialization would also work when no dynamic fields would be used?
Like deserializing some json into a JToken field (or JsonElement in case of 'System.Text.Json')?

I guess it would be possible to define an interface which provides the necessary methods for serialization and deserialization and allow the implementation to be injected into GraphQLHttpClient...

If we can then declare a generic for the "unknown type" fields (JsonElement by default) you would be set without manually deserializing queries afterwards (and able to use the websocket).

[rose-a]

the downside would be that we wouldn't be able to use attributes like [JsonIgnore]or [JsonPropertyName] anymore...

[sidhants]

So I suppose deserialization would also work when no dynamic fields would be used?
Like deserializing some json into a JToken field (or JsonElement in case of 'System.Text.Json')?

I guess it would be possible to define an interface which provides the necessary methods for serialization and deserialization and allow the implementation to be injected into GraphQLHttpClient...

If we can then declare a generic for the "unknown type" fields (JsonElement by default) you would be set without manually deserializing queries afterwards (and able to use the websocket).

Thats a very good suggestion and would make things flexible. I think the main concern is compatibility of System.Text.Json as there were a lot of dependencies that Unity or other platforms did not like. (I will give it one more shot though to rule it out)
newtonjson still seemed to have good support for il2cpp platforms. is that a possibility to revive/use without dynamic features with the injected code idea?

[rose-a]

newtonjson still seemed to have good support for il2cpp platforms. is that a possibility to revive/use without dynamic features with the injected code idea?

Yeah that's what I'm thinking too... with newtonsoft at least I would personally be able to build custom converters to achieve the things which are currently done with those properties in the primitive classes...

Guess this is somehow possible with System.Text.Json too, but I didn't figure out yet how to just override its behaviour for one layer (say "making the data field always lowercase) and leave the rest to the default serializer...

@sidhants Please check if the deserialization of an arbitrary object back to a JToken works on Unity

[sidhants]

newtonjson still seemed to have good support for il2cpp platforms. is that a possibility to revive/use without dynamic features with the injected code idea?

Yeah that's what I'm thinking too... with newtonsoft at least I would personally be able to build custom converters to achieve the things which are currently done with those properties in the primitive classes...

Guess this is somehow possible with System.Text.Json too, but I didn't figure out yet how to just override its behaviour for one layer (say "making the data field always lowercase) and leave the rest to the default serializer...

@sidhants Please check if the deserialization of an arbitrary object back to a JToken works on Unity

Yes. Going to do some tests this weekend with the pre-release.

[DamianMehers]

There is a big issue with Newtonsoft and AOT compilation which renders the generated code way too big to be used in some circumstances (see the "The 126MB Watch app" here.)

So Newtonsoft would not work for me, but if it makes sense for the general case then I can do a raw HTTP POST of the GraphQL query and then parse the result myself using something like SimpleJson which is used in the pre-GraphQL GitHub APIs.

[rose-a]

@DamianMehers does SimpleJson have a common base type for deserialized stuff (like JToken or JsonElement)? What happens if you deserialize an arbitrary JSON object to object?

Im trying to get around adding a complete string-returning interface to GraphQLClient by exactly defining the return type (which should work with basicly every Json library).

The biggest problem for this are the "Extension" fields on both GraphQLResponse and GraphQLError, for they can be "a map of anything" (the spec says "The response map may also contain an entry with key extensions. This entry, if set, must have a map as its value.").

[DamianMehers]

@DamianMehers does SimpleJson have a common base type for deserialized stuff (like JToken or JsonElement)? What happens if you deserialize an arbitrary JSON object to object?

Im trying to get around adding a complete string-returning interface to GraphQLClient by exactly defining the return type (which should work with basicly every Json library).

The biggest problem for this are the "Extension" fields on both GraphQLResponse and GraphQLError, for they can be "a map of anything" (the spec says "The response map may also contain an entry with key extensions. This entry, if set, must have a map as its value.").

I believe it does but I think this is an edge-case and that sooner or later System.Text.JSon will be supported on Xamarin so I would not worry. I'll hand-POST/decode the response from my Apple Watch app for now.