How to fetch association from field datafetcher

[marceloverdijk]

This is a bit of a follow up to #18 but the question is different.

Let's take this example:

type Query {
    shows: [Show]
}

type Show {
   title: String
   director: Director
}

type Director {
   name: String
}

The codegen generates a Director class and a Show class and the latter has a getDirector() method.

And the implementing data fetchers could be something like:

@DgsData(parentType = "Query", field = "shows"
List<Show> shows() {
    // Get list of shows from persistent layer, but without the director.
    // We also convert the show from the persistent model class to the generated DGS type.
    // Note that the persistent Show model class has a reference to the Director (like a `directorId`, which cannot be stored on the generated type)
    var shows = ...;
    return shows;
}

@DgsData(parentType = "Show", field = "director")
Director director(DataFetchingEnvironment dfe) {
    // How to get the director now?
    // dfe.getSource() would return the codegen generated `Show` which has no reference to the `directorId`.
    var director = ...
}

In the director data fetcher I could retrieve the persistent Show (again) - using like showRepository.getShow(dfe.getSource().getId()) - and from there get the directorId and query the Director.

I wonder if there is a better way?

PS: Without DGS my Show class returned by the shows datafetcher would contain the directorId but would not be exposed in the GraphQL schema. With the codegen generated classes this is not possible, so I'm looking for a nice pattern to implement this.

[paulbakker]

I think I understand the problem; to be able to load the director you need a field that your internal datas structure has, but is not represented in the schema, and thus not on the generated type.
If you return an instance of the generated type from the shows data fetcher, that's what you get back from getSource.

This problem is introduced because the director data fetcher requires context that's only available in the shows data fetcher. I'm sure there are multiple ways to get this to work, but my first approach would be to create a DataLoader to load directors, and invoke that data loader from within the shows data fetcher where you still have the directorId.

[marceloverdijk]

Yes this is a better pattern with a "backing object" containing other needed data.

This is indeed similar as I do in a vanilla graphql-java project.

Don't know why I did not came up myself extending/wrapping the dgs code generated classes.

Personally I prefer extending instead of wrapping but that's a personal choice, but while thinking about I would maybe even prefer more implementing an interface!

Did you ever think about having the option to generate Java interfaces complementary to the generated classes? E.g. with a generateInterfaces option similar as generateClient.
The the data fetchers would then expose these interfaces as the contract. Internally I could use the codegen generated classes (as they should implement the interfaces as well) or in situations where I need more I simply create a custom implementation; e.g. a simple data class.
The benefit using codegen is still huge as I'm guaranteed with the schema contract.

Wdyt? Worth to create a feature request?

[paulbakker]

Using interfaces would work. I'm personally not a huge fan of it, it feels like ending up with more types than really needed, but I'm not opposed to it either.

[marceloverdijk]

@paulbakker I tested a bit further with the DGS framework and I think my need for having interfaces being generated increased.
Not absolutely necessary, but let me explain.

Building on my previous example, and adding persons(page: Int = 0, size: Int = 10): PersonPage! to the query.

Query {
    person(id: ID!): Person
    persons(page: Int = 0, size: Int = 10): PersonPage!
}

type Person {
    id: ID!
    name: String!
    countryOfBirth: Country
    nationality: Country!
}

type PersonPage {
    items: [Person!]!
    pageInfo: PageInfo!
}

type Country {
    id: ID!
    code: String!
    name: String!
    continent: Continent!
}

type PageInfo {
    hasNextPage: Boolean!
    hasPreviousPage: Boolean!
    totalCount: Int!
    totalPages: Int!
}

Like I said internally I can use a custom DTO extending the generated Person like:

@Data
@EqualsAndHashCode(callSuper = true)
public class PersonDTO extends Person {

    private String countryOfBirthCountryId;
    private String nationalityCountryId;
}

For the person(id: ID!): Person query this works fine, but for the generated PersonPage this won't work that nicely.
It generated:

public class PersonPage {

  private List<Person> items;
  private PageInfo pageInfo;

  ..
}

Here the list also needs to be List<PersonDTO> items for the same reasons to retrieve the country of birth and nationality later.
I cannot simply extend the PersonPage here but should create a custom class without any relation the PesonPage anymore, like:

public class PersonPageDTO { // cannot extend PersonPage to have List<PersonDTO> items

  private List<PersonDTO> items;
  private PageInfo pageInfo;

  ..
}

With this setup I will agree it will work, but losing the contact with the generated PersonPage is not what I like.

Now, if for Person and PersonPage an interface would have been generated (let's say IPerson and IPersonPage for the example) I could have used:

public class PersonPageDTO implements IPersonPage {

  private List<IPerson> items;
  private IPageInfo pageInfo;

  ..
}

and I would fully comply to the generated GraphQL schema contract of IPersonPage.

[driptaroop]

@paulbakker That is a nice pattern indeed. Although it would work for most of the usecases, there are some cases (like @marceloverdijk added), I would also think that generating an interface might be required.

If we're using Kotlin, using this pattern is a bit challenging because the generated data models would be data classes which cannot be extended (since data classes are final by design). so in order to use this pattern we have cannot simply extend the generated model and add other parameters. we have to write separate data classes manually which would defeat the purpose of using the generated models as contract. In this case also it would be great to have an interface that can be extended.

[willyxiao]

Does generateInterfaces work for kotlin? Right now, I see that it works for language = "java" but I don't see any interfaces generated with language = "kotlin"

[paulbakker]

@marceloverdijk I've created a PR with new docs showing the different options around this topic if you want to review: Netflix/dgs#10.

[marceloverdijk]

Yes that looks very good! I left a comment at the PR with a remark.

[torbenkeller]

To reduce the amount of boilerplate code, but still using the InternalShow aproach, could be schema tagging. I am thinking about something like this:

type Show {
  @internal id: ID
  title: String
  reviews: [Review]
}

The framework could then ignore all fields annotated with @internal and the codegen plugin could add those fields to the generated data classes.