Hey everyone first of all, thank you so much for your great feedback, questions and thoughts! We apologize for the confusion as well as for the delayed response. In this post, we want to reply to the concerns and questions that were raised previously in this thread.
On a demo project, the additional resolvers are non-trivial. On a real production application, it’s resolver mania. @Lawjolla
It is true that the client requires you to implement type resolvers for types that have relations to other types. Note that @Mark_Petty’s comment is very much in line with our thinking that resolvers can be auto-generated (using
graphql-resolver-codegen ) to save writing boilerplate code. If your application schema is very similar to your Prisma GraphQL schema, schema delegation and Prisma bindings might be a great fit for your use case as well. (Note that you can also combine using the Prisma client and bindings in the same application.)
is it actually required to define all our graphql types and resolvers independently of the service @Findiglay
It is not a hard technical requirement to define GraphQL types independently of your Prisma service but we highly recommend to do so. The Prisma client is best to use it when your Prisma GraphQL schema should be decoupled from your application schema. In these cases, you have more control over the application layer by redefining the types in the application schema. If your application schema is very similar to the Prisma GraphQL schema, the more suitable approach might be to using Prisma bindings (i.e. schema delegation) with
Should it replace the binding/ delegation approach , should it offer an alternative, or does it aim to expose prisma to the consumer application in a sort of RPC style approach (Not technically, but use-wise) @Moritz
The Prisma client is intended to be an alternative to Prisma bindings and it is perfectly fine to use them together in the same application. As was mentioned by @kratam,
$delegate has been removed from the Prisma client API to make the use cases for both approaches more clear:
- Prisma client: Simple, and flexible API with convenient method chaining but without schema delegation but with full type-safety
- Prisma bindings: Main use case is implementing a GraphQL server with schema delegation based on the resolvers’
prisma-binding package will not be deprecated and can, of course, be used in production applications in the future!
(Side-note: We apologize for the confusion we caused through the wording in the beta announcement blog post. We updated "The Prisma client […] replaces Prisma bindings as a way to access data in your applications." to "The Prisma client […] can be used as an alternative to Prisma bindings as a way to access data in your applications")
An aspect that I am noticing is that you cannot query relation fields of objects that are returned in a list? So, I cannot query users and return all their blogPosts as an example? @Lawjolla
As @Kratam pointed out correctly, it is possible to retrieve relations by using the
$fragment API. You can of course also use
$graphql directly. Also note that we’re working on an API design that will make this possible in the future (more info here).
it’s not very efficient to retrieve everything from the DB if the client only needs the ids @kratam
This can also be solved using the
$delegate from the Prisma client, we’re making a clear distinction between the Prisma client and Prisma bindings.
Prisma bindings have schema delegation as their core feature and thus serve a very specific use case: Building GraphQL servers where the application schema is very similar (and should be strongly coupled) to the Prisma GraphQL schema.
Prisma client serves a more general purpose with a more flexible API. It can be used beyond the use case of building GraphQL servers and also might be the better tool when application schema and the Prisma GraphQL schema should be largely decoupled. Finally, a very important aspect are entirely type-safe resolvers which is extremely complex to achieve with schema delegation but really simple with the Prisma client (and a tool like
Another reason for removing schema delegation functionality from the Prisma client was because we wanted the API / feature set of the Prisma client to be consistent across languages, but schema delegation only exists in the JS ecosystem.
We also apologize for the lack of examples and documentation. We’re working hard on improving that
EDIT: A number of examples for using the Prisma client can be found here. To learn how to build GraphQL servers with the Prisma client, check out this tutorial on How to GraphQL.