Generate interfaces for schema types defined in schema in kotlin projects

[mr-nothing]

When I'm trying to generateInterfaces for kotlin language with use of generateJava task, they are not generated.

I saw ticket here that touch on this topic and it was stated that it is probably a feature of not a first priority.

I could probably add some context to highlight that this is pretty vital thing to have in kotlin based projects.

Let's take a look at the following setup:

type Team {
    id: Int
    parentTeam: Team!
    childTeams: [Team!]!
}

Now I'm trying to organize my dataloaders and data fetchers as optimal as possible.
In kotlin projects I have the following options and none of them looks optimal to me:

• Option 1: manually create interface for your types (not optimal from contract/schema perspective)

  • Create ITeam interface:

  interface ITeam {
      id: Int
      parentTeam: Team
      childTeams: [Team!]!
  }
  type Team implemets ITeam {
      id: Int
      parentTeam: ITeam!
      childTeams: [Team!]!
  }
  

  Then data fetcher will be something like this:

  @DgsData
  fun fetchParentTeam(
      dfe: DgsDataFetchingEnvironment
  ): CompletableFuture<Team> {
      val parentTeamId = dfe.getSource<Team>()?.parentTeam?.id
      return parentTeamId?.let {
          val loader: DataLoader<Long, Team> = dfe.getDataLoader(TeamDataLoader::class.java)
          loader.load(it)
      }
  }
  

  I case of relational database on val parentTeamId = dfe.getSource<Team>()?.parentTeam?.id line I have access to parent team id since it is ...toOne relation and I don't need additional db queries to find it out.

  Also in data loader I do this:

  @DgsDataLoader
  class TeamDataLoader(
      private val teamService: TeamService,
      private val gqlDtoBuilder: GQLDtoBuilder
  ) : MappedBatchLoader<Long, Team?> {
  
      override fun load(keys: MutableSet<Long>): CompletionStage<Map<Long, Team?>> {
          return CompletableFuture.supplyAsync {
              val results = teamService
                  .getTeamsByIds(keys)
                  .associate { it.id to gqlDtoBuilder.build(it) }
                  .toMutableMap<Long, Team?>()
  
              for (key in keys) {
                  results.putIfAbsent(key, null)
              }
  
              results
          }
      }
  }
  

  Looks good so far but the query for such a schema is not that concise as it could be:

  teams {
      parentTeam {
           id
           ... on Team {
               parentTeam
               // etc.
           }
      }
  }
  

  From client perspective it looks weird and doesn't feel right when performance backend stuff affects contract with external clients (another backend services, frontend, etc)

• Option 2: not optimal from support perspective. We can use local context and it is good all in all but in a long team it looks a bit error prone since every time we do a fetch of Team type we need to remember to pass local context in all data/entity fetchers. If we don't do that we got an error. Moreover if we get an additional field in schema like teamLead we need to populate it everywhere we populate local context.
  If project's graphql contract is not 100% covered with tests it could lead to errors on test/prod environments and with graphql request variety it is pretty difficult to keep test coverage on these high levels.

• Option 3: not optimal from performance perspective. We can fetch parentTeam with use of separate join db query and separate data loader logic but it is obviously not that fast and produces extra load on microservice itself and database.

• Option 4: looks promising, but has some java<->kotlin interop issues. In this cause we have the same interfaces like in option 1 but clients don't see them and we can extend them the way we like and use to carry info required by fetchers.

• Option 5: ideal option. Have interfaces generated for kotlin projects too. The same as option 4, but java<->kotlin interop boilerplate is not there.

Could you please share if there any plans to make generateInterfaces available for kotlin?

Thank you very much!

[congotej]

Hi @mr-nothing!
Thanks for providing context on this, and we definitely understand that this would be valuable for Kotlin. We will add this to our backlog for future enhancements. However, due to other priorities, we most likely will not be able to get to it immediately. If this is a time-sensitive requirement for your project, we always welcome contributions from our community.