Feature request for DGS Codegen: Allow interface generation for input types

[krutikavk]

Hi,

Similar to interfaces generation for data classes, having interface generation enabled for input types can be useful to extend functionality for input classes as well.

Use-case Walkthrough

Example of a use-case for interface type: https://github.com/krutikavk/sparseupdate-poc/tree/dynamic-proxy-no-intermediate

This design employs use of dynamic proxy to extend the functionality of any generic input class to identify presence of input arguments from client from a single object.

Consider the below schema and a sample class design:

type Query {
    show(id: ID!): Show
}

type Mutation {
    updateShow(input: UpdateShowInput!): Show
}

type Show  {
    id: ID!
    title: String
    releaseYear: Int
}

input UpdateShowInput {
    id: ID!
    releaseYear: Int 
    title: String
}

Design:

DGS Mutation can now use extended functionality proxyObject.isFieldSet(String fieldName) to identify if an input field is provided by the client. Instead of deducing the same information from 2 objects i.e. DGS data fetching environment and input argument, single proxy object holds persistent state for the mutation.

1. Data Fetcher in POC using above design
2. Generated classes including additional interface IUpdateShowInput for input type
3. Dynamic Proxy support classes

Happy to discuss further.

Thank you!

[krutikavk]

Hi @paulbakker @srinivasankavitha Can you possibly review the feature request and suggest if it's a good one to proceed with?

[krutikavk]

Hi @paulbakker @srinivasankavitha,

Tagging you if are able to direct me to an acceptable solution for the feature request and your thoughts on any more use-cases for the same.

I have added a sample PR for the feature: Netflix/dgs-codegen#766

Approach:

1. Similar to generation of interfaces for DataTypeGenerator, I have added support to add interface for InputTypeGenerator from config flag generateInterfaces.
2. You can test the feature by setting generateInterfaces flag for codegen.

I'd be interested to hear if there are any adjustments or further suggestions for the feature request and the use-case. I'd be happy to work with you to improve on the PR for any edge cases and test cases if the general direction is acceptable. Thank you!

[paulbakker]

Hi @krutikavk, sorry for the slow reply, we were pretty busy preparing for the 10.x release before the holidays.

I had a look at your prototype and did some more experimentation.
Using a proxy the way you show doesn't add a lot of value IMO, because you would have to do the proxy creation inside the datafetcher, which adds a lot of boilerplate code. At that point I think it's actually easier to just use the isArgumentSet utility method in the DgsDatafetchingEnvironment directly.

While I'm not convinced that proxies add much value over the isArgumentSet, I did some more prototyping using Bytebuddy.
With Bytebuddy we can create proxies more dynamically, so that you don't have to add extra code is a datafetcher. It also has the benefit that it can make the input objects implement the extra interface dynamically, so we don't actually need to add this to codegen.

I shared the example here: https://github.com/paulbakker/dgs-bytebuddy-sparseupdate.
Let me know what you think.

[krutikavk]

Hi @paulbakker Thank you for your input, we are currently analyzing the solution suggested.

[krutikavk]

Hi @paulbakker
Thank you for reviewing the POC and your example! We did a careful review of the suggested method and have concerns about modifying the code at runtime which may pose security risks.

Additionally, the existing implementation of the isArgumentSet method provides this functionality in a way that does not completely meet our architectural requirements. We need to propagate field presence state between layers (from API to Service Layer) and we’d like to encapsulate that state data within a single DTO object that would carry data and field state (including presence data) to minimize boilerplate code. For that, for instance, we’d like to have field presence state at every object level, and not at the top of the input object tree.

Based on our previous interactions, we think that input object interfaces would help us to implement this mechanism without major changes to DGS Codegen and no changes to DGS runtime. Please let us know your thoughts, appreciate your support and understanding.