You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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-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.
Additional context
https://github.com/FasterXML/jackson-annotations is the Jackson-example I'm used to regarding annotations in a separate module.
The text was updated successfully, but these errors were encountered: