Implement 'addMissingResolvers' feature about graphql-binding HOT 5 CLOSED

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.

from graphql-binding.

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

from graphql-binding.

+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 ?

from graphql-binding.

Would be neat to be able to first check auth and then return the forwardTo('db')

from graphql-binding.

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 - GraphQL Mesh uses a few interesting mechanisms for merging multiple sources, like transforms and handlers, including using the new schema stitching introduced in GraphQL Tools v6 and Apollo Federation and query planner as as an optional strategy.

I believe this is a superior way of merging multiple sources, manual, remote or any...

But, if you think addingMissingResolvers or something similar is missing in GraphQL Mesh, please feel free to open a new issue on the GraphQL Mesh repo.

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

from graphql-binding.