Overriding controller in GraphQL (additional to REST API)
Yana Teine
Now: GraphQL doesn't utilize the controller system like it did in v4. REST Controllers and GraphQL resolvers are separated.
Request: please, add overriding controller in GraphQL (as it was in v3) in addition to REST API.
I
Ignacio Alessio
I agree, having a single place to implement logic shared by REST and GraphQL is required. +1 to this request.
Alexander
I would like to second this request. In the v3 version there was one place where developers could implement logic shared between REST API and GraphQL -> a controller. Now that they are decoupled it created an inconvenience. See below:
Assuming the ShadowCRUD is enabled and Strapi generates standard types, queries and mutations for all the content-types. Now I want to alter the behaviour of many of those queries and mutations.
In Strapi v3 I could just implement that logic in the controller and be done with it. Simple and concise.
In the Strapi v4 there is no place like this any more. I have to register an extension for graphql now and re-define the queries and resolvers that I want to alter the behaviour of. This is unnecessary boilerplate that adds nothing at all and is only required because there is no more an overriding controller layer for GraphQL.
One way of solving this for me would be to change generated graphql resolvers to call core services rather than directly calling
entityService
APIs. In this case, we could implement the logic in the service layer and it would apply to graphql resolvers too.