Expose all queries and mutations as resolvers about graphql-binding HOT 7 CLOSED

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.

from graphql-binding.

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

from graphql-binding.

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

from graphql-binding.

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

from graphql-binding.

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

from graphql-binding.

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

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 - 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!

from graphql-binding.