Generate interfaces for schema types defined in schema in kotlin projects
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
ITeaminterface:
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?.idline I have access to parent team id since it is...toOnerelation 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)
- Create
-
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
Teamtype 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 liketeamLeadwe 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
parentTeamwith 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
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Ö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