Expose programatic API for executing graphql queries/mutations via the `keystone` instance

Update: This feature has been implemented as keystone.executeQuery. See https://v5.keystonejs.com/keystone-alpha/keystone/#keystoneexecutequeryquerystring-options

---

Original Post:

A suggested API is:

    keystone.createItem('Session', {
      outputFragment: `
        id
        posts {
          id
          title
        }
      `,
      variables: {}
    });

Where createItem matches our GraphQL API naming for create<List> (so we’d have ones like keystone.update<List>/ keystone.delete<List>), and 'Session' is the list we’re operating on.

Internally, this should follow all the same rules as a HTTP request that triggers a query which adds an extra complication: How can we ensure that the Apollo Server injects the correct context and runs the query through all the same error formatting, etc? It doesn’t appear that apollo-graphql exposes a programatic API. Perhaps we have to fake it and do a localhost http request to the listening port internally? Is there an overhead with doing that?

[dcousens]

My own diy patch on a keystone instance takes the form of

keystone.query = function runQuery (query, variables = {}) {
  const context = keystone.getAccessContext(SCHEMA_NAME, {})

  return keystone._graphQLQuery[SCHEMA_NAME](query, context, variables)
    .then(({ errors, data }) => {
      if (errors) throw new Error(errors[0])
      return data
    })
}

Where SCHEMA_NAME comes from, is up to how you configure keystone and your app-graphql. I think it defaults to admin…

This returns a Promise, so you can do await keystone.query('query ...', { ... }) etc

[molomby]

Bumping this 👍🏼 – If we want app developers to use the GraphQL API as their primary way of interacting with the DB, we need an easily accessible, programatic interface to the schema. Usually this would be used without access control (although I guess it would be handy to sometimes impersonate a user. I imagine developers often also want to skips any hooks.

I agree with @gautamsi in that, some times you’ll have an existing context (inc. req object, etc.) and might want to reuse or pass it through. Far more often though, whether serving an HTTP request or operating in another context (like a worker), devs will want to query independently from their own context (if that make sense). Put another way, the privileges a user has are very different to the privileges needed by the code that serves that user.

Involving an HTTP stack or mocking up express-style req objects, etc. seems like a very bad idea to me. HTTP is network transport protocol, we’re communicate within a node thread. Conceptually, GraphQL has nothing to do with HTTP; it’s a query language. We should maintain that conceptual separation wherever possible.