Resolver middleware

[jasonkuhrt]

Perceived Problem

• there is no way to run centrally controlled logic before a resolver in the framework
• @nexus/schema allows it but that requires the user going into the schema component and schema component plugin system

• like so:

  import { schema } from 'nexus'
  import * as NexusSchema from 'nexus/components/schema'
  
  schema.use(NexusSchema.plugin({
      onCreateFieldResolver(config) {
          // config.builder
          // config.fieldConfig
          // config.parentTypeConfig
          // config.schemaConfig
          // config.schemaExtension
          // ...  
          return NexusSchema.plugin.completeValue(/* ... */)
      }
  }))

Ideas / Proposed Solution(s)

• adding middleware could be simplified to:

  import { schema } from 'nexus'
  
  schema.middleware((config) => {
      return { /* ... */ }
  })

• need to revisit some schema plugin things, like completeValue, why do we need it and if/how can we stop needing it

[Weakky]

Status update

A first iteration is now in the pipeline in #688. This iteration intentionally provides very little abstraction over the @nexus/schema middleware system.

There's a number of ways we could enhance the current API by providing a higher level abstraction.

The current API looks like this:

schema.middleware((config) => {
  // Can return `undefined` before returning the middleware to skip its creation
  // eg: To exclude `Query` from the middleware, you would do:
  // if (config.parentTypeConfig.name === 'Query') { return }

  return async (root, args, ctx, info, next) {
    // Middleware implementation
  }
})

Abstracting even more onCreateFieldResolver

The API could look like this

schema.middleware(async (root, args, ctx, info, next, config) => {
  // Your middleware
})

Type selection API

By abstracting the underlying API even more, we lost the ability to skip the creation of a resolver. We therefore need some API to be able to optionally select on which type to apply the middleware. Here are some ideas:

a. Fluent API

// Apply only on Query and Mutation type
schema.middleware(async (root, args, ctx, info, next, config) => {
  // Your middleware
}).only('Query', 'Mutation')

// Apply on all types except Query and Mutation
schema.middleware(async (root, args, ctx, info, next, config) => {
  // Your middleware
}).except('Query', 'Mutation')

Pros/cons:

• Lack of static type-safety for the root and args params

b. Option API

// Apply only on Query and Mutation type
schema.middleware(async (root, args, ctx, info, next, config) => {
  // Your middleware
}, {
  only: ['Query', 'Mutation']
})

// Apply on all types except Query and Mutation
schema.middleware(async (root, args, ctx, info, next, config) => {
  // Your middleware
}, {
  except: ['Query', 'Mutation']
})

Pros/cons:

• Less elegant that the Fluent API
• Enables static type-safety for the root and args

c. Fluent API v2

// Apply only on Query and Mutation type
schema.pick('Query', 'Mutation').middleware(async (root, args, ctx, info, next, config) => {
  // Your middleware
})

// Apply on all types except Query and Mutation
schema.omit('Query', 'Mutation').middleware(async (root, args, ctx, info, next, config) => {
  // Your middleware
}).except('Query', 'Mutation')

Note: We could use only and except instead of pick and omit

Pros/cons:

• Unintuitive API. When typing schema.omit|pick, we don't know that its for middleware. We actually don't know what it's for at all
• Enables static type-safety for the root and args

Type selection capabilities

Furthermore, we could make the type selection go beyond just string matching, and allow regex patterns to match type names.

eg:

.only('Query', 'User', /Stripe.*/, 'Stripe*')