or should i just use prisma client?

Hi there 👋 it's up to you which one want to use, but the Prisma client is the recommended approach. Unless you have a good reason to use bindings, you probably want to go with the Prisma client as your default choice 🙂

thank

Subscriptions and nested queries of arrays are not supported with client if I’m not mistaken so I use prisma-bindings for flexibility and scalability. Would love to see the example projects and docs implement both concurrently on that note!

Hi @jackgray, subscriptions are supported in the client via the

$subscribe

property 🙂 what do you mean with "nested queries of arrays"? In general, anything that you can do with the bindings should also be possible with the client (except for schema delegation).

From the docs: “...you cannot query relation fields of objects that are returned in a list, e.g.: prisma.users().links()”

Ah I see, you're right that this is currently a limitation of the fluent relations API. However, you can still send these nested queries for lists using

$graphql

or

$fragment

🙂 Also note that it's likely that the client API will be adjusted and this will also be possible via the fluent API in the future 👍

Also the tutorial for subscriptions uses bindings and I remember reading somewhere else that prisma-client did not support them but that must have changed or I’m missing a piece of the puzzle. Can you point me to where in the docs would help me understand the difference between fluent api and the “$” usage?

The fluent API lets you fetch relations via dot-notation, e.g.

user({ id }).posts()

or

user({ id }).car().manufacturer()

.

$fragment

and

$graphql

let you query Prisma by submitting fragments or GraphQL queries as strings. I think the code snippets on our website give a good overview on that, e.g. here https://www.prisma.io/client/client-typescript/

Just to make sure I don’t abandon prisma-bindings for the wrong reasons, is there any case that would prefer the use of bindings? The docs still reference that forum post about understanding Prisma clients value proposition where the consensus seems to be that bindings and client are intended as a dual track, yet this doesn’t sound like the case now.. no examples that I have found actually use a “dual track”

I think the main reason to use bindings is the schema delegation. I’m still using bindings since this is very useful for my applications. Simply pass the

info

object and don’t need to worry about anything else 🤷‍♂️ I think this feature was originally part of Client as well but was removed afterwards for some reason. I’d like to know if there is any problem or antipattern with this or is just to make it different from bindings. @nikolasburk

Schema delegation is definitely not an anti-pattern and if it works well for you that's great 🙂 Apart from some differences in their APIs, there are two core differences between the client and the bindings: - Bindings support schema delegation via the

info

object which can be convenient sometimes - The client on the other hand enables full type-safety for implementing resolvers (which you might not care about if you're using plain JS) The Prisma client is the recommended approach because: - We don't want that people need to understand schema delegation as a prerequisite for using Prisma - The API of the client is more flexible and allows for other use cases than building GraphQL server - We ❤️ type-safety 🙂

Makes sense, thanks for the information! I’d adopt the client if it had the schema delegation but I guess I’ll stick to bindings for now 😅