Code generation and field data fetchers

[victorlevasseur]

Hello,

I'm yet to try out this new starter for making GraphQL servers.
However, I have a question concerning the code generation of the data types.

Will it always generate a Java POJO with all the fields listed in the GraphQL type?
It can be annoying when some fields are resolved using their own data fetchers. If that's the case, those fields should not appear in the POJO as they can be resolved by their data fetcher. How do we adjust the code generation feature for this?

[paulbakker]

There are multiple relevant answers to this question, let me try to explain the different options.

Yes, by default, the generated POJOs contain all fields of the types in the schema. Note that the structure of the POJO is unrelated to how you structure your data fetchers. Let's look at an example:

type Query {
    shows: [Show]
}

type Show {
   title: String
   actors: [Actor]
}

type Actor {
   name: String
}

This would generate two POJOs: Show and Actor.
The generated Show class has two fields, title and actors.

Independent of how the Show class looks, you can structure your data fetchers in different ways.
For example you could have a single data fetcher which fully constructs a show instance, including its actors.

@DgsData(parentType = "Query", field = "shows"
List<Show> shows() {
   return List.of( Show.newBuilder().title("Ozark").actors(List.of(....).build());
}

If however you would want to have a separate data fetcher for the actors field, you could still do that.

@DgsData(parentType = "Query", field = "shows"
List<Show> shows() {
   return List.of( Show.newBuilder().title("Ozark").build());
}

@DgsData(parentType = "Show", field = "actors")
List<Actor> actors() {
   return List.of(Actor.newBuilder().name("Some famous person").build());
}

In the latter case, the shows data fetcher just creates an instance of Show, but leaves the actors field empty. That field is added later by the actors data fetcher. What that means, is that the fact that the Show class has an actors field, doesn't prevent you to have a separate data fetcher for actors, and it doesn't really get in your way. Generally I would recommend just keeping all fields that are in the schema.

However, if you really don't want to have a specific field, there is a @skipcodegen directive you can use in the schema.

[victorlevasseur]

Ok, this makes sense.
Thanks for the detailed answer.

[hikuley]

@paulbakker I wanna try it out with Kotlin but I didn't find gradle configuration to do this? How can implement the Code generation plugin with Kotlin Language?

[paulbakker]

On a Kotlin project it will typically auto-detect the Kotlin plugin, and generate Kotlin classes instead of Java.
You can also force the language with a setting:

generateJava {
   language = "KOTLIN"
}

Note that it's still using the generateJava config block. That's an artifact of the past when we didn't have Kotlin support yet, but aside from the badly chosen name it's fully Kotlin compatible.
You should see Kotlin data classes etc. get generated.

[hikuley]

Thank you for quick response, I tried it out like here:https://github.com/hikuley/kotlin-spring-boot-graphql-ap. it works, what I did: I set up a small configuration in gradle build script file as follow and then it works as I expected.

@OptIn(ExperimentalStdlibApi::class)
tasks.withType<GenerateJavaTask> {
    language = "KOTLIN"
    schemaPaths = mutableListOf("${projectDir}/src/main/resources/schema") // List of directories containing schema files
    packageName = "com.kuleysoft.generated" // The package name to use to generate sources
}