Further leverage schema-first GraphQL and directives

The GraphQL portion of this is extremely attractive, and I think there’s the potential to extend it all the way to schema definition and more with schema-driven design.

Instead of:

keystone.createList('Todo', {
  fields: {
    name: { type: Text },
  },
});

We could define:

type Todo {
  name: String!
}

This is similar to Prisma’s datamodel.graphql

Even for the views I like the concept of defining some things in GraphQL, for example:

query Todos($completed: Boolean){
  todos(completed: $completed) {
    name @title("title")
  }
}

Would automagically generate a page showing all the todos, create a checkbox to modify the query arguments, and output the results in a table with the name field in a “title” column.

@description("Create a new Todo")
mutation AddTodo($name: String! @placeholder("Pick Up Milk...")) {
  createTodo(name: $name) @refetch("Todos")
}

This would create a form for a new todo with a title and placeholder, it could be combined with above.

Obviously can extend to mutations and custom UI elements could be defined via fragments on types:

query Users {
  avatar @fragment("profile")
}

[MadeByMike]

Directives look like a great way to do a lot of things, but wouldn’t this force us to have a set of pre-defined access control functions/rules?

The way our access control works, you can define any function you want. You get access to an authentication object and might want to do any number of complicated things.

Here is an example from an application I’m working on where I have a list of Comments. For read access I want to filter the results to only include items that have been approved unless the authenticate user is an admin user, in which case I will return all comments.

const Comment = {
  fields: {
    comment: { type: Text }
    approved: { type: Checkbox },
  },
  access: {
    read: ({ authentication: { item } }) => {
      if (item.isAdmin) {
        return {}; // Don't filter items for admin users
      }
      // Return only approved comments
      return {
        approved: true
      };
    }
  }
};

This is a really simple example but I think the point is we don’t want to force users to have a ‘role’ based access control system or any other specific system. I think that is a strength of Keystone. It doesn’t force you down any path.

That said I am still very interested in these ideas because we want to make the most common path easy without sacrificing the flexibility.

One thing we could do is define a bunch of common directives for things like access control so that people can use them if they want. We could then feed these into a middleware that generates Keystone lists and then allow users to augment these lists further before initialising them in Keystone.

What I’m thinking is some kind of schema-to-list package that people can opt-in to. A standalone package that gives you these options and perhaps some more opinionated options around access control etc… I think that would be useful for some people.

[timleslie]

This is an interesting discussion for the archives, but I don’t think there’s any further action to be taken in the core repo based on this ticket, so I’m going to close this issue 👍