Expose all queries and mutations as resolvers

It seems like a common sentiment amongst Prisma users is that they just want to expose the entire generated CRUD API to the client, with a few custom pieces. See the following for evidence of that:

• https://github.com/graphql-binding/graphql-binding/issues/40
• https://github.com/graphql-binding/graphql-binding/issues/37

To achieve this, no one wants to copy over parts of the generated schema nor resolvers in any way if possible. That is cumbersome and messy. As a partial solution to this problem, I propose exposing mutation and query resolver objects that have all of the generated mutation and query bindings wrapped as resolvers. This might be done on the Binding class, exposing a queryResolvers property and a mutationResolvers property. Essentially, I think we need to incorporate functionality like the following:

export function prepareTopLevelResolvers(resolverObject: Query | Mutation) {
    return Object.entries(resolverObject).reduce((result, entry) => {
            const resolverName = entry[0];
            const resolverFunction = entry[1];
            return {
                ...result,
                [resolverName]: async (parent, args, context, info) => {
                    return await resolverFunction(args, info);
                }
            };
    }, {});
}

This function does the automatic wrapping and allows you to very easily expose the entire generated API in your application server. See this write-up for a full example application and explanation: https://medium.com/@lastmjs/advanced-graphql-directive-permissions-with-prisma-fdee6f846044

[lewisblackwood]

Thanks for the write up @lastmjs! My experience with Prisma is very similar to what you’ve described. I’d like to expose the majority of the generated database API, with the addition of permissions/authentication. I’d like to keep duplication of the generated schema in my schema/graphql to a minimum. Ideally I’d be able to replicate the graphcool-framework API I had previously.

@schickling would it be possible to get an update on the upcoming tooling to simplify this approach?

It’s tricky to track the progress on the above across #40, #83, and graphql-middleware.

If there’s soon to be a recommended approach to this, with tooling to support, I’d like to go with that. Otherwise, I’ll follow @lastmjs’s approach in their blog.

[schickling]

Thanks a lot for bringing this up @lastmjs. This seems to be indeed a very common pattern which we’ll try to simplify a lot with some upcoming tooling in the next few weeks.

For everyone interested in this, please provide more information about your use case(s) in the comments. Things we have heard so far:

1. Adding authentication & authorization rules
2. Add input validation rules to mutations
3. Extending schema
4. Hiding certain fields / arguments (but keep majority of the schema)
5. Generate code based on Prisma GraphQL API