Can codegen generate DgsComponent skeleton?

[tawabocah]

During learning netflix DGS, I use this schema.

type HelloWorld {
  text: String!
}

type Query {
  allData: [HelloWorld]
  oneData: HelloWorld
}

schema {
  query: Query
}

Then according to getting started, we need to follow these rules:

1. create class with @DgsComponent and implement method with @DgsQuery.
2. method name must be exact same with schema

Which means, this is the required dgs component.

@DgsComponent
public class HelloWorldDgsComponent {

    @DgsQuery
    public List<HelloWorld> allData() {
    }

    @DgsQuery
    public HelloWorld oneData() {
    }
}

This skeleton seems follow specific rules above. I wonder if gradle codegen only generate data types, or also we can configure it to generate query skeleton?

Thanks

[srinivasankavitha]

Yes, the gradle codegen plugin does generate barebones data fetchers as example code under build/generated-examples. Note that you would need to copy over these examples to the actual location and populate that with the required data fetcher logic. Also this generated code is not included as part of your build.

[tawabocah]

Thanks a lot

[ilterpehlivan]

Hi, As a follow-up question; is there any reason why not to generate the queries,mutations as interfaces which can be implemented in the services ? Something like below ;

Auto-Generated

interface HelloWorldService{
List<HelloWorld> allData();
HelloWorld oneData();
}

@DgsComponent
public class HelloWorldDgsComponent {
    @Autowired HelloWorldService helloWorldService;
    @DgsQuery
    public List<HelloWorld> allData() {
       return helloWorldService.allData();
    }

    @DgsQuery
    public HelloWorld oneData() {
    }
}

Implemented by developer

@Service
public class HelloWorldServiceImpl implements HelloWorldService{
    ....
}

This will force schema-changes to be implemented and easily to be validated in CI
Thanks

[srinivasankavitha]

We've just never encountered any use case scenario for it thus far. Also, what would be the advantage for doing so? In addition, we also have clients that make queries and do not necessarily implement services.

[ilterpehlivan]

well this is for schema-first development style, basically schema evaluation and development can go in parallel in different team members/teams, as long as there is validation and sanity check as part of the CI.

For instance:

• Schema is under the implementation by Developer
• Meanwhile Architect got a new requirement from PO and needs to change a query function
• Architect changed it but forgot to inform developer (Happens a lot :) )
• So there is no authority left to detect and react this unless Architect hopefully realizes this

This is already very well integrated into the existing REST code generators so I thought it could be also fitting here!