Mark fields / types / interfaces and skip GrapQL CRUD generation

Users GraphQL
1

Is there any way to mark some fields / types / interface of the GraphQL schema in order to skip their CRUD generation.
For example in schemas with a lot of interfaces, I would like to exclude all the CRUD operation for the interface in order to expose only the operation for the types which actually implement the interfaces

2 Likes
2

We do have the @remote directive which can be used to annotate types that you don’t want to generate CRUD operations for. See https://graphql.dgraph.io/doc/custom/directive.

Though it might not work for your use case right now as we don’t allow non-remote types to implement remote interfaces.

We could look into adding another directive which allows you to achieve this or look into allowing non-remote types to implement remote interfaces.

3

I think that a new directive would be more clear.

interface WithName @skipCRUD {
  names: [String!]!
}

type Person implements WithName  {
   age: Int
}

so that the getWithName and queryWithName, … will not be generated

1 Like
4

Agree, though I think at some point we’ll have to make it more flexible so as to be able to selectively turn off add/update/query or delete.

5 
@generate(
  add: Boolean
  update: Boolean
  delete: Boolean
  query: Boolean
  get: Boolean
)

And then unless === false generate like normal.

3 Likes
6

This would be available in 20.11 via the @generate directive. See more details at https://dgraph.io/docs/master/graphql/schema/generate

2 Likes
7

It will be useful to also have the @generate directive operational on fields and not only on OBJECT | INTERFACE. My use-case is to populate the fields via @lambda mutation and then query via the auto-generated queries. Consider this hypothetical example:

type Person  {
   name: String! @id
   age: Int
   father: Person @generate(mutation: {
        add: false,
        update: false
    })
}

type Mutation {
    addFather(name: String!, father: String!) @lambda
}

In this example, the add and update mutations for type Person are auto-generated but will exclude the field father. These mutations can be used to add Person objects and update their age. The addFather lambda mutation can be used to add father to a Person (i.e., set the field Person.father using lambda dql). Alternatively, the planned @webhook directive can be used to populate the father field. Since the query mutations are not disabled for the field father, users can use the auto-generated query queryPerson or getPerson to query Person including the father field without writing a custom resolver.

There are few advantages to this approach, most notably its flexibility, simplicity and the ability to perform deeply nested queries that are not trivial using @custom directives.

@pawan @rajas @abhimanyusinghgaur any thoughts?

2 Likes
8

So, as I understand this, you are looking for something which can define when to include a particular field in mutation input?

I have proposed something similar here: GraphQL error: Non-nullable field was not present in result from Dgraph - #6 by abhimanyusinghgaur
Can you take a look, and confirm if that would suffice your use-case?

1 Like