How to test extensions on federated types?

[terminalnode]

Say I have something like this:

@GraphQLName("User")
@KeyDirective(fields = FieldSet("id"))
class User(@ExternalDirective val id: Long) {
  fun myField(
    env: DataFetchingEnvironment,
  ) = env.getValueFromDataLoader(...)
}

What's a good strategy for testing this? The way I see it there's a lot worthy of testing here. There's checking that the field is added correctly to the type, checking the name of the field, that the dataloader is working correctly and so on.

I buy that testing that the external directive and gql name are correct is impossible without running it in a dev/release environment and integrating with other services, but testing the full flow from dataloader => field => entity => graphqlserver (but perhaps not => ktor/springboot/webserver) should be possible somehow?

Our setup is a Ktor server, and in our tests we use a test server where we currently add mocked entities of the linked type to be able to access this, but it's not a great setup and you can easily get into a position where you need to manually edit the schema.graphqls.

[dariuszkuc]

Hello 👋
It sounds like you are asking is how to test entities? In order to be able to hit myField you need an instance of your type which is resolved through _entities query -> at a minimum you would need to construct a schema and then you can manually execute entities query, e.g. executing query like this

query ($representations: [_Any!]!) {
    _entities(representations: $representations) {
        ...on User { 
            myField
        }
}

with variables

{
    "representations": [
        {
            "__typename": "User",
            "id": 123
        }
    ]
}

Currently it is not great user experience so if you have any ideas how to improve it let us know! We (Apollo) are looking into ways how to simplify the entity resolution logic but it may take a while for the feature to land and be made widely available (it requires composition and query planner changes). For the time being _entities query is the only option to instantiate entities.

--- FYI

• @external is no longer required for the key fields so you should remove it
• graphql-kotlin validates whether your @key field set references fields that exist on a type

[terminalnode]

Thanks, this is exactly what I was looking for! While not the most ergonomic solution, it works for my purposes. 👍🏻

Using the apollo3 kotlin client I'm able to get what I want using this query:

query MyQuery($user: _Any!) {
  _entities(representations: [$user]) {
    ...on User {
      myField { ...MyFieldFragment }
    }
  }
}

and querying it with this:

MyQuery(mapOf("__typename" to "User", "id" to id))

I also tried this query:

query MyQuery($id: Long!) {
  _entities(representations: [ { __typename: "User", id: $id } ]) {
    ...on User {
      myField { ...MyFieldFragment }
    }
  }
}

Hoping that I could call it like this:

MyQuery(id = 1)

But it seems the id is not inserted into the query here. The parsing exception doesn't show the inputs (for good reason I guess), but my guess is that it queried id: $id literally.

As for ideas on how to improve it, I'm not exactly sure how much is dictated by the GraphQL standard and how much is implementation specific. For the graphql query I think it would've been nice if User was an _Any! and I could just do something like query MyQ($user: User) { _entities(representations: [$user]) }, but I'm guessing that might not be compatible with the GraphQL type system separating inputs and types.

If the query is kept as is currently, then a representation builder of some kind would go a long way I think:

// Instead of this:
MyQuery(mapOf("__typename" to "User", "id" to id))

// This:
MyQuery(User(id = 1)) // this would be great
MyQuery(User.withKeys(id = 1)) // if constructor isn't possible
MyQuery(User.withKeys("id" to 1)) // perhaps more realistic?

[dariuszkuc]

As for the reason why second query didn't work (i.e. one with { __typename: "User", id: $id }) -> it is a valid query and you should be able to use it from raw WebClient HTTP calls. I believe apollo-kotlin (or any other typesafe client) will most likely have some issues with handling of custom scalar values. Any is a pretty hacky workaround to allow arbitrary map input...