Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: configure codegen to add @sharable directive in PageInfo type #1762

Closed
yamalameyooooo opened this issue Jan 3, 2024 · 6 comments
Closed
Labels
enhancement New feature or request

Comments

@yamalameyooooo
Copy link

yamalameyooooo commented Jan 3, 2024

Please read our contributor guide before
creating an issue. Also consider discussing your idea on
the discussion forum first.

Describe the Feature Request

Add custom directives like @cacheControl(maxAge: 30) @shareable @tag(name: "public") to generated types when using codegen to types like Pageinfo and other Connection Types and reflect in the SDL of a running graphql project/server

the generated PageInfo Type should look like below in the SDL:

type PageInfo @cacheControl(maxAge: 30) @shareable @tag(name: "public"){
    hasPreviousPage: Boolean!
    hasNextPage: Boolean!
    startCursor: String
    endCursor: String
}

Also can the Connection Type can have 1 more additional field totalCount so that the SDL can look like below:

Connection{
  edges:[Edge!]
  pageInfo:PageInfo!
  totalCount:Int!
}

This will be beneficial to show in UI something like showing results 1-10 out of 500(totalCount) records

Describe Preferred Solution

Allow configuration in pom file in pom or gradle to mention to add @sharable tags in PageInfo tags while generating it and result it in the final SDL

Describe Alternatives

None as such

@yamalameyooooo yamalameyooooo added the enhancement New feature or request label Jan 3, 2024
@yamalameyooooo
Copy link
Author

@kilink can we have something like this?
Ultimately i want to generate the Connection types with custom directives on those in SDL so that it can be used in a federated supergraph in codegen, as defining relay based pagination types and managing them in all the subgraphs is not helping when we have to write the logic manually all over again for each query

@yamalameyooooo yamalameyooooo changed the title feature: configure codegen to add @sharable tag in PageInfo type feature: configure codegen to add @sharable directive in PageInfo type Jan 3, 2024
@yamalameyooooo
Copy link
Author

yamalameyooooo commented Jan 5, 2024

to be precise the @connection generates the relay pagination types dynamically and adds them to schema,
we would like those types to have federated directives support , like let dgs know when generating those types in schema ,
add federated directives like @sharable, etc what ever the user passes maybe give arguments to @connection directive so that the end result would be like :

type PageInfo @cacheControl(maxAge: 30) @shareable @tag(name: "public"){
    hasPreviousPage: Boolean!
    hasNextPage: Boolean!
    startCursor: String
    endCursor: String
}

@yamalameyooooo
Copy link
Author

@srinivasankavitha

@srinivasankavitha
Copy link
Contributor

HI - codegen is not used to generate SDL. It only generates POJOs based on a statically defined SDL. The framework handles basic dynamic generation of SDL for pagination. If you require more custom logioc, directives, it would be better to manually add that to your SDL rather than using the @connection directive.

Hope this helps.

@kilink
Copy link
Member

kilink commented Feb 8, 2024

I think for your custom PageInfo, you should just add it yourself to your schema. The pagination support will only add a PageInfo type if one doesn't already exist.

For the Connection types, I could see an argument for adding a flag to the directive to have it generate the totalCount field. Probably in the meantime you could add a @DgsTypeDefinitionRegistry provider that transforms the Connection type and adds the field?

@paulbakker
Copy link
Collaborator

Closing this issue because we want to avoid adding more flags and customization to Codegen whenever possible to avoid complexity of the plugin. Since there is a workaround for this issue we shouldn't add it to codegen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants