Shared types in GraphQL Federation (@shareable)

Support
,
34

Hi @zaid

thank you for your research!

A workaround via SDL transformation could be interesting, but a more sustainable solution would be better. Otherwise the next one will stumble over the same problem again. :wink:
Either it is a bug in the Java libraries or it should be fixed in the Tyk gateway.

I also did some research on the Java side, here are my findings:

1. Schema definition in SDL

  • The library responsible for printing the SDL is “federation-graphql-java-support” which is developed by Apollo.
  • It uses the schema printer of the graphql-java library and explicitly sets an option to always print the schema definition to the SDL.
    (ServiceSDLPrinter.java)
  • No idea if this behavior is according to the specification, but it makes sense somehow:
    Yes, it would be possible to leave out the schema definition in the SDL as long as the default root operation types (Query, Mutation, Subscription) are used. But in case these differ from the standard the gateway must somehow know which types are used in the upstream service.
    (See also: SchemaPrinter.java)

2. Empty Query type

  • This is certainly an edge case that occurs when a service does not define its own queries.
    You are right, from the spec it appears that object types must have at least one field.
  • But, there is another paragraph in the GraphQL spec that states:

The query root operation type must be provided and must be an Object type. (reference)

  • This again sounds more like the query type must always be there, even if no queries are defined…
  • I found the following (old) isssue in the github repo of the federation library:
    Empty `type Query {\n}` in the sdl response ¡ Issue #23 ¡ apollographql/federation-jvm ¡ GitHub
  • There it was explicitly decided in this case that type Query without brackets and field list is the right way to go. Here is the link to the “Objects” part of the GraphQL Spec: GraphQL Spec 3.6 Objects
  • If I understand this correctly, the “FieldsDefinition” can also be omitted. So following this “type Query” would be correct according to the specification…

For the above reasons, I would rather see this as a fix in the Tyk Gateway. What do you think?

Thanks again for the support and have a nice weekend!
Sebastian