Kotlin aware module

[IceBlizz6]

Alright @kaqqao, let's figure this out.

As you stated the idea here is to create a 'Kotlin aware module' that can be plugged into graphql-spqr.
This will use Kotlin reflection to pick up properties and resolve their nullability and naming.
I have the Kotlin knowledge and you have the spqr code base knowledge.

We need to figure out some of the basics first.

Do you have thoughts on how this module will be plugged into the library?
Maybe it would just be a method that we call on the GraphQLSchemaGenerator, this would enable the Kotlin reflection.

Will this module exist within the graphql-spqr code base?
or is this something imported from a separate dependency?

Need to identify the areas in code base where it is necessary to swap between java and Kotlin module. After that then maybe easiest solution is to create an interface which would include methods to pick up properties.

[kaqqao]

While I'm pretty certain your original issue wasn't really about SPQR, the stuff I said there about a Kotlin module is still true. E.g. people made a custom TypeMapper that understands Kotlin's nullable types, an InclusionStrategy that ignores companion objects etc. (I don't know if any of these are correct, mind you)
So what would be ideal here is to create a module that collects all these Kotlin-aware extensions in one package.

It would basically look something like this:

class KotlinModule : Module {
    override fun setUp(context: SetupContext) {
        context.getSchemaGenerator()
                .withTypeMappers(NullableTypeMapper())
                .withInclusionStrategy(CompanionIgnoringStrategy())
                ... //whatever makes sense, I don't actually know what customizations are neccesary
    }
}

Then, to use it, you'd just register it with the generator:

generator.withModules(KotlinModule())

A Module is really just a convenient way to register multiple extensions at once. Nothing special.

[IceBlizz6]

My project currently has 4 of these calls.

GraphQLSchemaGenerator()
	.withTypeMappers(KotlinNullableTypeMapper()) // Applies nullability from Kotlin properties
	.withNestedResolverBuilders(KotlinAwareResolverBuilder()) // Removes Companion objects
	.withSchemaTransformers(PreserveBooleanPrefix()) // Preserves isX name prefix for boolean properties
	.withTypeMappers(KotlinFlowAdapter()) // Flow support for GraphQL subscriptions

The code for these are quite messy at the moment, but maybe i can try to clean it up a bit.

There may be some performance penalties here as currently with this solution it seems like graphql-spqr will discover the members through java reflection first, then my code will try to lookup those members through Kotlin reflection after.

May be faster to let Kotlin make the initial discovery to list members, but that will probably require some more changes to your code base.
I can't entirely promise that it will be worth it.

[kaqqao]

Almost everything imaginable can already be customized, so it's highly improbable that anything in the core codebase would have to change. It's probably a matter of finding the right place to plug in an extension.

[IceBlizz6]

Hey
Haven't forgotten about this, it's a bit slow cause of real life stuff.
I encountered another problem that i hoped you would help me with.
It's related to the kotlin module so figured i could take it here.

So i have some code like this:

class Operations {
    @GraphQLQuery
    fun doQueryWithNull(): SomeClass<Int?> { // <== Notice the Int? here (it means bar is nullable in SomeClass)
        error("Not implemented")
    }

    @GraphQLQuery
    fun doQueryWithoutNull(): SomeClass<Int> {
        error("Not implemented")
    }
}

class SomeClass<T>(
	val bar: T
)

I know that you are not familiar with Kotlin, But i hope that the code above is somewhat understandable.
In Kotlin the '?' means that it is nullable.
The problem here is related to nullable generics.

One operation will return with a nullable field and the other as non-nullable.
So the schema i'm getting from this is:

type Query {
  doQueryWithNull: SomeClass_Integer!
  doQueryWithoutNull: SomeClass_Integer!
}

type SomeClass_Integer {
  bar: Int!
}

So i'm fiddling around with my KotlinNullableTypeMapper class,
and i'm not sure if it's possible to solve this using only a TypeMapper.

The generated schema i would have expected could look something like this:

type Query {
  doQueryWithNull: SomeClass_Nullable_Integer!
  doQueryWithoutNull: SomeClass_Integer!
}

type SomeClass_Nullable_Integer {
  bar: Int
}

type SomeClass_Integer {
  bar: Int!
}

How could a plugin generate additional type like this from a generic?