Support ability to make a dynamic request about nodes

[chemdrew]

Yeah, unfortunately... Let me play with some of the serialization pieces with this in mind and see if there could be a better option

[chemdrew]

Hi @tonysparks, thanks for the submission!

I'm a little curious on the added value from building queries in this way as opposed to the current API definition. Could you provide some use cases for this?
My main concern is that decoupling the requests from the models and making them so dynamic removes the ability to easily cache them (#2). I would be more inclined to expose the Property tree used to construct the query string in the requestEntity; starting from a base data model and extending it from there.

[tonysparks]

Hello chemdrew,

My current use case is for schema stitching (i.e., a graphql proxy service the merges multiple disparate graphql services into one).

As an example, a query may come in that has multiple queries that resolve to different backend GraphQL endpoints. It would be nice to be able to construct the (sub)query based on the fields being queried for - which wouldn't be known upfront.

[chemdrew]

I'm having a hard time understanding how this library plays into schema stitching. Schema stitching is handled by the GraphQL server implementation and the models should all be exposed upfront there; so this client would be able to interface with it as it would any GraphQL API

[tonysparks]

Sorry, I wasn't very clear.

I'm working on a GraphQL server schema "stitcher". This server, needs to make GraphQL calls to other GraphQL servers. It will receive GraphQL requests, the server then needs to determine which GraphQL servers to call and build the appropriate request (enter in Nodes).

In other words, I'd like to use Nodes on a GraphQL server to call other GraphQL servers, the catch is the requests are not known ahead of time (only the full schema is).

[chemdrew]

Ah, I had an inkling that's what you were getting at, thanks for clarifying!
I'm still concerned about exposing a way to build an entirely dynamic query but am toying with the idea of exposing the Property tree used to construct the query on the requestEntity.
Would you be able to make use of the Property tree combined with the use of the @GraphQLIgnore annotation?
That way you could build the models for the GraphQL services with each field ignored so you could dynamically populate them but still have it serialized back

[tonysparks]

That could work -- however, that would increase the amount of work significantly (I would need to create POJO's for each schema).

[Favorlock]

I can also second the OP's request. Our GraphQL API for the Enjin Coin trusted platform has quite a number of parameter configurations for the various queries and mutations which has been a big headache to support. My solution was (as the OP suggested) and using string replacing on a template to allow dynamic parameters, but it would be nice to have a structured API like what you're working with the ability to dynamically set parameters.

[JacobMountain]

@tonysparks @Favorlock Have you looked into GraphQL Braid for schema stitching?