Netflix / Netflix/dgs-codegen

Generate interfaces for schema types defined in schema in kotlin projects

Offen
#653 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Vorherrschende Sprache
Kotlin
Sterne
217
Forks
116
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

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)
        }
    }
    

    In 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!

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne damit, die Aufgaben generateInterfaces und generateJava für Kotlin-Projekte nachzuverfolgen, und sieh dir das zugehörige Issue #200 für den bisherigen Kontext an. Erledigt ist die Aufgabe, wenn Kotlin-Projekte über generateInterfaces Schnittstellen für im Schema definierte Typen generieren können und das Verhalten durch geeignete Tests verifiziert ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
graphql, kotlin
Bereich
backend-api-design, tooling
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Muss geklärt werden
Anfängerfreundlichkeit
30/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.