Expose only specific resolvers

Issues GraphQL
, , ,
#1

Hi,

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

#3

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.

1 Like
#4

@abhimanyusinghgaur, nice idea

That looks familiar:

1 Like
Custom Mutations - Graphql
#5

Sounds great!!

#6

@abhimanyusinghgaur maybe for fields, you can add @readonly/@hidden or something like that

2 Likes
#7

Marking this as accepted. We’ll tackle it as part of the next sprint.

2 Likes
#9

if you can add support for the hidden fields it will be great too
example:

type User{
    email: String! @hidden(unless: $isAuthenticated: "True") 
    username: string @id
    ...
}

or

type User{
email: String! @hidden(if: $isAuthenticated: “False”)
username: String! @search(by: [hash]) @id
…
}

#10

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?

#11

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

#12

Merging @CRUD and @withSubscription directive

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.

An Example of @generate directive:

type Person @generate(
	query: {
		get: true,
		query: false
	},
	mutation: {
		add: true,
		update: false,
		delete: true
	},
	subscription: true
) {
  id: ID!
  name: String!
}

This will give greater control to Users on what APIs to generate for each type.
The existing @withSubscription directive will be deprecated.

1 Like
#13

Generate Directive feature to expose only specific resolvers has been merged into master, https://github.com/dgraph-io/dgraph/pull/6760 . We will soon add related documentation.

1 Like
#14

Documentation can be found at https://dgraph.io/docs/master/graphql/schema/generate. This would be part of the 20.11 release.

1 Like