Expose all queries and mutations as resolvers

[lastmjs]

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:

• Thoughts on resolver forwarding #40
• Implement 'addMissingResolvers' feature #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

[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

[picosam]

@schickling may you share a bit more about what you're planning for this if you can? Thank you!
P.S. The 5 points you mentioned are already super useful.

[stevenkissack]

We need to append on extra geolocation related values determined by the server to a couple of queries and it should be invisible to the user that the returned response is filtered in any way. I guess this concept would allow us to not rewrite the entire schema for this use case? We are using Node & GraphCMS

[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.

[macrozone]

i am evaluating prisma and also react-admin

react-admin has three graphql-adapters:

• simple
• graphcool
• prisma/opencrud

the prisma one works against the prisma-server, but of course this is not ideal in practise as you want to add authentification, modifications, etc. as mentioned in this thread here.

I am now about to introduce a graphql server that uses the prisma client, but i am unsure which "dialect" for crud-operation i should take. I would like to stick with the prisma one, so I would also like to see a best-practise to forward prisma's crud api

[Urigo]

Thank you for reporting.

In the last few months, since the transition of many libraries under The Guild's leadership, We've reviewed and released many improvements and versions to graphql-cli, graphql-config and graphql-import.

We've reviewed graphql-binding, had many meetings with current users and engaged the community also through the roadmap issue.

What we've found is that the new GraphQL Mesh library is covering not only all the current capabilities of GraphQL Binding, but also the future ideas that were introduced in the original GraphQL Binding blog post and haven't come to life yet.

And the best thing - GraphQL Mesh gives you all those capabilities, even if your source is not a GraphQL service at all!
it can be GraphQL, OpenAPI/Swagger, gRPC, SQL or any other source!
And of course you can even merge all those sources into a single SDK.

Just like GraphQL Binding, you get a fully typed SDK (thanks to the protocols SDKs and the GraphQL Code Generator), but from any source, and that SDK can run anywhere, as a connector or as a full blown gateway.
And you can share your own "Mesh Modules" (which you would probably call "your own binding") and our community already created many of those!
Also, we decided to simply expose regular GraphQL, so you can choose how to consume it using all the awesome fluent client SDKs out there.

If you think that we've missed anything from GraphQL Binding that is not supported in a better way in GraphQL Mesh, please let us know!

---

In the context of that particular issue - There are other, individual tools that generates queries and mutations from a given schema, no matter the source.
We are not fans of that approach but if you need it, there are tools for that that are not tied to how the schema and API were created.

We're looking forward for your feedback of how we can make your experience even better!

[macrozone]

for reference: if someone uses prisma2 and react-admin, we built a new, maintained data-provider for it. It has a helper function for the backend that exposes all crud operations for a given resource

https://github.com/panter/ra-data-prisma