Can someone please tell me what stack of tools should I use to start a new Prisma Project?

If you are using

schema delegation

then bindings is the way to go. Otherwise, client is the way to go. This discussion will help you make the decision better -> https://www.prisma.io/forum/t/help-understanding-prisma-clients-value-proposition/4394/17?u=divyendu_singh We are working on making the docs more consistent and better!

Thank you for quick reply. The post has made clear that, to the best of my understanding, Binding should be used when schema-delegation with

info

is need, while Client provides a simpler and more intuitive API like "getting a property from big object". Is my understanding close enough? But when my schema has a few layers of relations with interfaces and query fragments, I already found it difficult to implement the resolvers. In such case, I should keep using binding, am I correct? Thanks again!

Hey @hinsxd 👋 it's completely up to you whether you want to go with bindings or the client 🙂 it's correct that the main use case of bindings is schema delegation, the client on the other hand comes with a simpler API that is not using the

info

object. If you feel comfortable with using Prisma bindings, there's no need to move away from that!

Glad to know that! I also want to learn how to migrate to Client. For example I have the following schema:

type Query {
  fooUsers: [User!]!
  barUsers: [User!]!
}
interface User {
  name: String!
}
type FooUser implements User {
  name: String!
  foo: [Foo!]!
}
type BarUser implements User {
  name: String!
  bar: [Bar!]!
}

when I query with prisma-binding, I have to implement custom resolvers for

FooUser.foo

and

BarUser.bar

. If I want to use the client, despite needing to implement resolvers for all fields, can I retrieve

fooUser.foo

directly with

foo: parent => parent.foo()

in

FooUser.js

?

Can you please show an example of what you mean?

From my experience, I couldn't do simple schema delegation for non-scalar relational fields with interfaces and fragments queries. With the above example, if I want to query

fooUsers{
  name
  ... on FooUser {
    foo {
      someValues
    }
  }
}

the default resolvers with prisma-binding could not return

foo

. I had to implement the FooUser resolver (suppose every object has a unique ID and it is always queried) like:

foo: (fooUser, _, { db }, __) =>
  db.query
      .user({ where: { id: fooUser.id } }, `{ name foo { someValues } }`)
      .then(( { foo } ) => foo)

But now with prisma-client, it seems to be more straightforward that it becomes

foo: ({ id }, _ , { prisma }, __) => prisma.user({ id }).foo()

Although I have to do this for every fields, they look exactly the same if I don't implement any logic. That's why I think it would be easy to write a generator for this.