graphql-client: Request to add API that returns string responses/errors rather than deserialized results
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’.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 2
- Comments: 25 (5 by maintainers)
If you are worried about copy/encoding operations, then you can ask to provide the result as a stream.
This is more useful than most people think. The option to have a high level typing should be optional and not forced. I would also prefer this. People shouldn’t be forced up to something. It should be an option, and people should be able to write code to achieve this. Serialization/Deserialization isn’t cheap. This will cause people to have to do it twice potentially. I, myself, am just forwarding JSON from a micro-service back to a client where it will be handled by TypeScript. I am not interested in the JSON at all on the gateway in the middle. As @sidhants said, It seems like it wouldn’t be hard at all, and be very useful, to have a Task<string> SendQueryAsync(…) as an option. Nobody is asking to get rid of the default member functions.
As far as how this would be handled over a WebSocketTransport, you would have to work with @joemcbride on that. As there is no metadata or any kind of properties you can tag along with a WebSocket frame. It’s all inside of the OperationMessage payload. However, I was reading the WebSocket RFC, didn’t get much out of it. Frames do have an extension property. The specification has reserved a few opcodes for extensions, and they just have to be negotiated on connection. Then you can add extension data to a WebSocket frame payload. That way, you wouldn’t have to deal with the WHOLE payload to grab the ID out of the frame/JSON at all. You would know exactly where it is at in the payload. Avoiding a deserialization. Just a little bit of information I figured I would offer.
EDIT I am using GraphQL over a WebSocket transport, and after looking at the code, I would be happy to even have graphql-ws sub-protocol OperationMessage.Payload as a string only. If I could have just the payload string, that would 100% satisfy my needs.
IGraphQLResponse.Data.ToString() will be fine for now. Thank you guys for everything.
Yes. Going to do some tests this weekend with the pre-release.