Support exposing Query/Mutation/Subscription fields (and not only functions)

[Martin Bonnin]

The following query class:

class RootQuery : Query {
    val hello: String = "Hello World"
}

is not considered valid and building a schema from it triggers a Invalid query object type - no valid queries are available error. This was surprising because in other objects, fields are recognized as valid.

Would it be possible to detect properties in addition to functions?

[Samuel Vazquez]

Hi @martinbonnin, thank you for opening this issue.

Currently top level objects do only process functions, while other objects process functions and properties, so in terms of logic consistency the schema generator logic could be updated, however, i don't see an specific use case where a top level field would have an static scalar as value.

Im most use cases, even getters, is always better to back data fetchers/resolvers to function calls, this, to truly honor the GraphQL execution engine.

We have seen many uses cases where folks invoke async operations in classes constructor arguments, so even by resolving an specific field of the object, all async operations are going to be executed in order to instantiate the object.

We believe that this feature request will add some extra logic for something that can be solved by just backing un the scalar to a fn call

class RootQuery : Query {
    fun hello(): String = "Hello World"
}

[Martin Bonnin]

The use case is conference presentations 😅 . I'm trying to show how easy the mapping from Kotlin to GraphQL using a minimal viable example. Ideally something like so:

Kotlin:

class RootQuery : Query {
    val hello: String = "Hello World"
}

GraphQL:

type Query {
  hello: String!
}

So no worries at all if it's too much hassle but I thought I"d ask. Feel free to close this issue and I'll use functions.

[Samuel Vazquez]

probably we need to update the docs to highlight the special treatment top level objects have.

Will discuss this internally and will reach back, IMHO while adding this is possible it wont add much real value and will add more complexity to the schema generator logic

[Martin Bonnin]

Thanks! FWIW, I started looking a bit into this and the first issue I found was didGenerateQueryField taking a KFunction

fun didGenerateQueryField(kClass: KClass<*>, function: KFunction<*>, fieldDefinition: GraphQLFieldDefinition): GraphQLFieldDefinition = fieldDefinition

Not sure if this can be changed to take something else. In all cases thanks for the quick response!

[Sarah Ksiyer]

Hi guys, its my first time setting up a GraphQL Server and I'm using this library. I'm having the same issue, how can I resolve?
Package: com.expediagroup:graphql-kotlin-spring-server
Version 4.0.0-alpha.1 and 3.5.0

Thanks

[Samuel Vazquez]

@sksiyer what is the issue you are facing ?

[Samuel Vazquez]

if its the ability to expose top level objects fields as properties, we currently don't plan to support that, its an specific use case that will add some unnecessary extra code.

what i would suggest is to wrap your property in a function

from

class RootQuery : Query {
    val hello: String = "Hello World"
}

to

class RootQuery : Query {
    fun hello(): String = "Hello World"
}

[Sarah Ksiyer]

My query is a function like so:

@Component class RootQuery : Query { fun hello(): String = "Hello World" }
I was able to resolve this by downgrading the springboot version from 2.7.0 --> 2.6.14
I read somewhere that there is a clash with 2.7.0