In our projects, we tend to separate the DTO/modelling layer from the actual endpoints/GraphQL-layer. This means that a separate Gradle (or Maven) module contains a set of model classes. If we want to include GraphQL-specific info on these models, we currently have to include the entire com.expediagroup:graphql-kotlin-schema-generator to gain access to the annotations.
Describe the solution you'd like
I'd like to suggest a strategy like Jackson uses, where the annotations are located in a separate module. This allows for including only the annotations instead of the entire generator within model-related packages, thus lowering the bundle size for those packages. It also ensures that the scope of GraphQL-related stuff in those modules is limited to annotations only, as currently one could "by accident" expose for instance a whole schema generator instance.
Describe alternatives you've considered
The alternative we're currently using is simply including the entire schema generator instead. This works as long as everyone is aware of the "risks" this may cause.
In our projects, we tend to separate the DTO/modelling layer from the actual endpoints/GraphQL-layer. This means that a separate Gradle (or Maven) module contains a set of model classes. If we want to include GraphQL-specific info on these models, we currently have to include the entire
com.expediagroup:graphql-kotlin-schema-generatorto gain access to the annotations.Describe the solution you'd like I'd like to suggest a strategy like Jackson uses, where the annotations are located in a separate module. This allows for including only the annotations instead of the entire generator within model-related packages, thus lowering the bundle size for those packages. It also ensures that the scope of GraphQL-related stuff in those modules is limited to annotations only, as currently one could "by accident" expose for instance a whole schema generator instance.
Describe alternatives you've considered The alternative we're currently using is simply including the entire schema generator instead. This works as long as everyone is aware of the "risks" this may cause.
Additional context https://github.com/FasterXML/jackson-annotations is the Jackson-example I'm used to regarding annotations in a separate module.