Imagining what a graphql schema would look like that allows auto-creating lists and detail view/editor

Post.graphql

enum PostStates { DRAFT, PUBLISHED, ARCHIVED }
scalar Date
scalar Html
directive @buildIndex on field
directive @defaultFirst on field
#...etc

type PostContent {
  brief: Html @editor(height: 150, wysiwyg: true)
  extended: Html @editor(height: 400, wysiwyg: true)
  full: Html @virtual @editor(hide: true)
}
input PostContentInput {
  brief: Html
  extended: Html
}

type Post @trackChanges @list(enabled: true, columns: "name, state|20%, author|20%, publishedDate|20%") {
  key: ID! @autoKey(from: "name") @unique
  name: String!
  state: PostStates! @buildIndex @defaultFirst
  author: ID! @relation(type: "User") @buildIndex
  publishedDate: Date
  image: CloudinaryImage
  content: PostContent
  categories: [ID!] @relation(type: "PostCategory")
  comments: [ID!] @relation(type: "PostComment") @virtual
}

input PostInput {
  key: ID
  name: String!
  state: PostStates!
  author: ID!
  publishedDate: Date
  image: CloudinaryImage
  content: PostContentInput
  categories: [ID!]
}

type Query {
  post(key: ID, name: String): Post
  filterPosts(state: PostStates, author: ID, category: ID): [Post]!
}

type Mutation {
  savePost(post: PostInput): Post
}

schema {
  query: Query
  mutation: Mutation
}

Based on the keystone definition in https://github.com/keystonejs/keystone-demo/blob/master/models/Post.js

So this would be a description for automatically creating a basic list/detail view admin UI for your data. See http://demo.keystonejs.com/ for an existing implementation of this concept, not based on GraphQL.

The idea is that if there is an editor/viewer registered for a certain type, it will be used to view/edit that part of the item, and the directives in the schema are used to automatically create a database and configure the UI.

Upon reflection, I'm not sure that directly tying the UI to the schema is a great idea, it would be better to auto-generate a starting form from the schema and change that.

Same for the DB I suppose. It is not that much work to maintain 3 kinds of schemas, each similar but with their own subtleties…