Add annotation to include extension function in schema

[de55]

📝 Description

An annotation @GraphQLExtensionFunction was added to include extension functions within the query.

Additional tests still need to be added. I wanted to get confirmation on adding this and on the syntax before continuing. My personal use case for this is that a lot of our code is autogenerated, and this allows me to add functionality to those classes.

Extension properties are not currently a part of this PR.

🔗 Related Issues

#383

[smyrick]

Do we need to add this annotation? Can we modify the existing SubTypeMapper to be able to get extensions methods, and just load those when we are running the function builder?

Then you can still exclude with GraphQLIgnore

https://github.com/ExpediaGroup/graphql-kotlin/blob/9eee16b2497bd882f1b56201158b7192ae16aba8/graphql-kotlin-schema-generator/src/main/kotlin/com/expediagroup/graphql/generator/SubTypeMapper.kt

[de55]

It is feasible to do it without the annotation. You would need to search for public static functions and then add them to the schema for the class that is the first parameter.

I did it with the annotation just so it was backwards compatible. Also not sure if there would be a performance hit looping through the methods.

[smyrick]

@de55 I am wondering now though if we want to encourage this at all. I know you have your specific use cases for adding more fields to autogenerated models but wouldn't it be better to redefine the GraphQL models as their own unique types so there is a separation layer of the GraphQL models from the models that are generated from I assume a downstream service.

[de55]

In my particular case, the auto generated code is specifically for the GraphQL service. This just allows some flexibility for object specific code.

The changes were easier to make by making the changes to the core package rather than implementing custom hooks, and I thought it might be helpful to others. But if you would prefer that it isn’t in this package, I can implement via custom hooks.

Also graphql officially supports an extended object, not sure if you would prefer the extension types have a specific syntax like:

https://www.apollographql.com/docs/graphql-tools/generate-schema/

const typeDefs = [`
schema {
query: Query
}

type Query {
bars: [Bar]!
}

type Bar {
id
}
,
type Foo {
id: String!
}

extend type Query {
foos: [Foo]!
}
`]

[dariuszkuc]

just a side note -> @de55 while the graphql-spec does support extension types, graphql-java currently does not (hence the workaround with @ExtendsDirective in federation). Personally I also don't think those extension functions should be marked as extended type in the schema.

I'm wondering whether including this annotation would make it somewhat confusing though - as I mentioned above federation has its own workaround to declare extended types and this annotation provides a way to add Kotlin extension function to the graph.

[smyrick]

Yea, I am leaning toward not supporting it as it would cause lots of confusion of how to include something in a schema, plus I think it may be more useful to use extension method on your schema models to add extra functions in for server side only without having to @GraphQLIgnore everything.

@de55 You said that you can still do the Reflection in your hooks right? I think that is the best approach for now but if we have a need for this later or more people asking about it we can re-open this discussion

[de55]

@smyrick @dariuszkuc It turns out I was not able to implement it through the hooks because I needed access to the generator, which creates a circular reference. I instead implemented it by inheriting from SchemaGenerator and overriding the objectType and interfaceType functions.

The only issue with this approach is that FederatedSchemaGenerator is final, so I had to copy/paste the code from that to my custom generator. Would you mind if that is made an open class?

[dariuszkuc]

The only issue with this approach is that FederatedSchemaGenerator is final, so I had to copy/paste the code from that to my custom generator. Would you mind if that is made an open class?

No issue there. Feel free to submit a PR to open it up.