-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement 'addMissingResolvers' feature #37
Comments
I would like this features too. I tried Prisma out but I reverted back to apollo. The main powerful of the Prisma to me is the auto-generated api for the underlining database, but I couldn't access those api directly from the client side; I had create "forwardTo" for every CRUD methods, it gets tedious pretty quickly. I know how to query database and create CRUD endpoint manually, as I use rethinkdb, and it is pretty easy to do so. If I can't utilize the auto-generated CRUD methods from Prisma, then Prisma does not save much trouble for me. What I want is I can from the client side, access Prisma CRUD apis and my own graphql apis at the same time. |
+1 on this one, upgrading from GCF to Prisma would mean forwarding almost everything by hand for me. 99% of my business logic is about CRUD operations, I only need one or two "schema extensions" for payment and user's basket, just like the 'full-example' example from GCF https://github.com/graphcool/graphcool-framework/tree/master/examples/0.x/full-example. However, I'm concerned that we would have no way to handle permissions doing this ? |
Would be neat to be able to first check auth and then return the |
@stevemu and @Weakky please take a look at this blog post: https://medium.com/@lastmjs/advanced-graphql-directive-permissions-with-prisma-fdee6f846044 It shows a simple way to automatically expose all of the generated Prisma queries and mutations as resolvers. You can easily add the few custom resolvers that you would like as well. Permissions are handled as custom directives. I feel the blog post shows a direct solution to each of your issues, let me know if you have any questions. |
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 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! 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. 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 - GraphQL Mesh uses a few interesting mechanisms for merging multiple sources, like I believe this is a superior way of merging multiple sources, manual, remote or any... But, if you think We're looking forward for your feedback of how we can make your experience even better! |
It would be nice if there was a
addMissingResolvers(bindingName)
function that would addforwardTo
resolvers for any root field resolvers that are not implemented manually.Use case. You import a (large) number of queries and mutations from a backend schema, and want
forwardTo
resolvers for most of them.The text was updated successfully, but these errors were encountered: