Thoughts on resolver forwarding

Based on recent feedback, I’d like to kickstart an open discussion about the state of resolver forwarding and potential improvements.

forwardTo is a great convenience function:

const { forwardTo } = require('prisma-binding')

const Query = {
  posts: forwardTo('db'),
}

Here, we forward the posts query from our GraphQL server to a Prisma API. However, as soon as we want to modify the behaviour by, say, checking authentication before resolving, we have to fall back to the full ctx.db.query call:

const Query = {
   posts(parent, { where, skip, last, first }, ctx, info) {
    await checkAuth()
    return ctx.db.query.posts({ where, skip, last, first }, info)
  },
}

The best way to tackle this at the moment is to write a little convenience wrapper to check authentication like so:

const Query = {
   posts: checkAuth(forwardTo('db'))
}

Can you come up with other scenarios where resolver forwarding falls short, and approaches to improve the entire experience surrounding resolver forwarding?

#37 is a great idea in that direction, but I’m sure there are more great approaches to be found 🙂

[schickling]

Update: We’re currently working on a new kind of GraphQL server framework which doesn’t require you duplicate your schema/resolver code while still making it easy to adjust/evolve your schema in an easy and (type-)safe way. (The best part: you won’t have to think about schema delegation or mess with the info object which is quite difficult to wrap your head around for newcomers.)

[lastmjs]

This blog post offers potential simple solutions to these issues: https://medium.com/@lastmjs/advanced-graphql-directive-permissions-with-prisma-fdee6f846044

It shows a simple way to automatically expose all generated queries and mutations, and to easily combine those with your own custom schema and resolvers. Copying schema information is kept to a minimum. Permissions are handled elegantly through custom directives. Let me know if you have any questions.