-
Notifications
You must be signed in to change notification settings - Fork 368
Description
We are currently in a bind because we cannot test the _entities federation endpoint when implementing FederatedTypeResolver<T> via a GraphQL query that is used for generating a test client via the gradle plugin.
The _Any type is typealiasd to String but the represesentations [_Any!]! is expected to be a List<Map<String,Any>> in the underlying framework code. Defining custom ScalarConverter<T> for _Any does not work as the representation array inner values are always treated as String when sending it via the generated clients even when we do custom conversion in a ScalarConverter.
As far as I know scalar types in GraphQL are always implemented with String as its underlying type which does not hold true for the special _Any type of federation in conjunction with the _entities endpoint.
Doing an API test for the crucial _entities endpoints at the GraphQL-query-layer seems like the way to go when doing application testing but we are currently forced to test the FederatedTypeResolver<T> directly which is a bit of a bummer.
Example:
query FederationTest($reps: [_Any!]!) {
_entities(representations: $reps) {
... on SomeData {
key,
someField
},
__typename
}
}
will generate the following query in the generated clients even when defining a custom scalar converter which interprets the _Any Strings as a map via Jackson and then converts it into a proper JSON object / map via the same ObjectMapper:
{
"variables": {
"reps": [
"{\"__typename\":\"SomeData\",\"key\":\"1\"}",
"{\"__typename\":\"SomeData\",\"key\":\"2\"}",
"{\"__typename\":\"SomeData\",\"key\":\"3\"}",
]
},
"query": "...", //omitted
}
compared to the correct:
{
"variables": {
"reps": [
{
"__typename":"SomeData",
"key":"1"
},
{
"__typename":"SomeData",
"key":"2"
},
{
"__typename":"SomeData",
"key":"3"
},
]
},
"query": "...", //omitted
}
We would appreciate any help / a way to test these federation endpoints via the test clients as certain contracts (e.g. not throwing exceptions when a single key cannot be resolved in a batch federation request) are testworthy and starting on the GraphQL layer is more thorough than actually invoking the FederatedTypeResolver<T> directly (which also needs a DataFetchingEnvironment).