graphql-java-support: Bump graphql-java to v16.1

[sachindshinde]

This PR is an iteration of the changes suggested in #84 (many thanks to the authors and commenters).

Summary of changes:

• Bump graphql-java to v16.1 in the pom.xml
• Rename ExecutionPath to ResultPath
  • Reason: This class was renamed in Rename ExecutionPath to ResultPath graphql-java/graphql-java#1962 to be more accurate.
• Add a dependency on org.slf4j:slf4j-api
  • Reason: This dependency used to be transitive, but is no longer transitive since upgrade to gradle 6.6 and a bunch of other dependencies graphql-java/graphql-java#2011 .
• Update FederationSdlPrinter to use graphql-java v16.1's SchemaPrinter
  • Reason: As described in graphql-java-support: Remove federation directive and type definitions from SDL and use stricter SchemaGenerator checks #53 , we use our own printer to avoid printing federation directive definitions and federation type definitions in SDL.
• Add a new flag called queryTypeShouldBeEmpty to the Federation.transform() overload that accepts a GraphQLSchema to indicate that the query type in the given schema should really be empty, and that the type only contains dummy fields to satisfy GraphQL validation.
  • Reason: GraphQL object types can no longer be empty because of a new validation introduced in New validation rules about type, field, argument graphql-java/graphql-java#1955 . To be clear this is in the GraphQL spec, but graphql-java hadn't been implementing it; this is an issue with federation SDL not being valid GraphQL.
    • This new validation means we need to remove the testPrinterEmpty() test, since we can no longer represent empty types in a GraphQLSchema object.
  • For users who use other overloads of Federation.transform(), all of this is invisible; we add the dummy field for them, and it's accordingly removed in SchemaTransformer.build(). This lets us maintain backwards compatibility with users who provide empty query type (or who provide no query type) in the common case.
    • Note that there's no way to avoid the compatibility breakage for users who build their own GraphQLSchema object, as they do this before they call this library. The best option here I think is to provide clear steps in the CHANGELOG.md for the fix.
• Simplify ExecutionResultImpl builder calls in FederatedTracingInstrumentation.instrumentExecutionResult()
  • Reason: There is now a copy method for this builder that accepts an ExecutionResult.

Note that this is a backwards incompatible version bump due to backwards incompatible changes in graphql-java v16 (e.g. the ExecutionPath -> ResultPath rename).

[smyrick]

@sachindshinde This PR looks good from my perspective as a library user. Is there anything else blocking the review?

[williamboman-pp]

Would be nice to get this in place so we don't get stuck on old graphql-java versions

[setchy]

Any further updates? Many of the libraries we depend on were just released over the weekend to use graphql-java:16.1 and this is the final one in our stack

[sachindshinde]

@smyrick @williamboman-pp @setchy
Apologies for the delays, I've finished changes to code and tests and taken this PR out of draft status. The only merge-blocker is that we'd like to run an RC in our own backend before cutting a release.

[setchy]

@smyrick @williamboman-pp @setchy
Apologies for the delays, I've finished changes to code and tests and taken this PR out of draft status. The only merge-blocker is that we'd like to run an RC in our own backend before cutting a release.

Great news - thanks @sachindshinde for the update

[williamboman-pp]

Let me know if you want help testing, we could deploy this to our staging envs as well

[pcarrier]

🎉

[sachindshinde]

Our backend showed no issues with the RC, so I've cut release 0.6.0.