Option to have the query and mutation classes extend another interface
See original GitHub issueThe example server has public class QueriesResolver implements Query, GraphQLQueryResolver
. What if Query
extended GraphQLQueryResolver
? Then you wouldn’t have to implement two interfaces on each resolver. We could have a new option that let you specify a fully qualified class name to have the queries extend. Same for the mutations.
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Interfaces and inheritance - TypeGraphQL
TypeScript has first class support for interfaces. ... As we need to generate unique query/mutation names, we have to create a factory function...
Read more >Unions and interfaces - Apollo GraphQL Docs
Unions and interfaces are abstract GraphQL types that enable a schema field to return one of multiple object types. Union type.
Read more >Extending GraphQL | Craft CMS Documentation | 4.x
A Mutation class defines named mutations that should be available, including consideration for scope access. Each mutation can have its own arguments and...
Read more >Codegen Options | graphql-java-codegen - GitHub Pages
Specifies whether api interface methods should have throws Exception in signature. apiReturnType, String, Empty, Return type for api methods (query/mutation).
Read more >Hot Chocolate GraphQL Extending Object Types To Split ...
Hi everyone,This video explains splitting large Query and Mutation Classes to separate classesThe entire session made as a ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I have actually avoided the
$TYPE
/${TYPE}
syntax on purpose in my proposal, because I’m afraid it will collide with the Maven/Gradle plugin configuration syntax, and may result in unexpected behaviour (empty string or build failure).Maven has a variable syntax exactly like that.
Gradle, at least when used with the Kotlin DSL, would also interpret
${...}
as a template variable in a string.Sorry to bring down the excitement 😅
@benmccann, thanks for creating the feature request. I was also thinking about this some time ago.
I very like the solution from @joffrey-bion with one minor comment. I would make the nested config so that in Maven it will look a bit prettier: