When using slash graphql automatically crud resolvers are exposed.
Sometimes I don’t want to expose all resolvers and let users of the API to only be able to make read-only requests for a certain type for example.
I know that it is possible to guard an endpoint with @auth directive but there is one problem with that:
Assume that I have an events management application and I want to allow for a user to add events and update or delete a specific event but not to delete many events at once.
Another example is when a user can query a certain type but only specific fields are eligable
For this, I guess GraphQL can provide a Schema directive for types like:
type User @CRUD(get: true, query: true, add: false, update: false, delete: false) {
id: ID!
name: String!
...
}
That would let users choose which resolvers are generated for each type.
For fine-grained use case like the two above, I guess you should be able to achieve them once we have custom JS resolvers working in Slash. They should be out soon. See Implement custom JS resolvers in GraphQL for more info about custom JS resolvers.
Seems like you want to hide certain fields based on a value in the JWT custom claims. Is that right? What’s the use-case that you hope to be supported by this?
An example from Github - If your are an unauthenticated user you can watch other users profiles but you can’t watch their email. Other usecases might be data that is visible only for users with a specific role. Example for that might be a patien and a doctor - the doctore can have access to the patient history and to some notes he wrote for himlsef about the patient and the patient can only see his precriptions and the doctor’s analysis conclusions.
These are arbitrary examples just in order to make clear what I meant.
you want to hide certain fields based on a value in the JWT custom claims
Yes but not only, hiding fields upon a query result might be helpfull too
Currently, there exists a @withSubscription directive to specify whether to generate subscriptions for types or not. The current discuss post is about having a @CRUD directive to specify whether to generate get, query, add, update and delete APIs for types.
Instead of having two separate directives to generate GraphQL queries of types, we propose having a single @generate directive which will have variables to specify whether to generate subscription queries and also other CRUD operations.