Prisma1: questions on the new 1.16 (beta) prisma-binding API

[beeplin]

Is your feature request related to a problem? Please describe.

when checking on the new 1.16 docs I found the query syntax of the prisma-binding has been totally changed (https://www.prisma.io/docs/1.16/prisma-client/api-reference/reading-data-javascript-rsc2/) .

In the 1.15 API we can always pass info into a query, like prisma.query.user({...}, info), to control the structure of the returned value. It seems that the 1.16 API no long has info parameter, and by default only non-link fields are returned. Now we can use prisma.user({id: 'xxx'}).posts() to get the related posts, but it is not clear how to do it when we have more than one joined fields, like posts and friends shown below:

query {
  user(...) {
    id
    name
    posts {
       title
    }
    friends {
       name
    }

Describe the solution you'd like

It might be better to keep the second info parameter to allow fine-grained control over the structure of returned value.

[divyenduz]

Thanks for reaching out and sharing your concerns. The new binding API is called "Prisma client" which is a new and intuitive way to access the Prisma API.

The new Prisma client API has the following goals:-

• Intuitive & type-safe API (provides with autocompletion and compile-time error checking for queries)
• You can still use $delegate together with info-> https://www.prisma.io/docs/1.16/prisma-client/api-reference/schema-delegation-TYPESCRIPT-pyl8/
• The new client also allows raw database access -> https://www.prisma.io/docs/prisma-client/api-reference/raw-database-access-TYPESCRIPT-pyl6/

Please let me know if you have further questions. You can find more about the Prisma client in this blog post -> https://www.prisma.io/blog/prisma-client-beta-ahph4o1umail/

[beeplin]

Thanks for the detailed reply :)

So I unnderstand that the previously binding API prisma.query/mutation.xxx is now simply moved to prisma.$delegation.query/mutation.xxx, right?

Previously we can pass a selection set string into the second parameter instead of the info object. But in the beta doc it says

Schema delegation is only applicable in the context of a GraphQL resolver function where the info object is available. 

So does it means the selection set string can no longer be supported?

[divyenduz]

Thanks. Yes your understanding is correct. The binding API is simply moved to the scope of $delegate as you suggested.

Let me clarify the line about "schema delegation" a bit, the new client API can be used in CLI tools, REST endpoints and is GraphQL agnostic in the sense that you don't need to know GraphQL to interact and use the client. Schema delegation is usable in context of a GraphQL resolver. This is the message we want to get across. Using custom selection set is still possible.

I will get in touch with the team to improve the wording. Thanks again for pointing it out.

Adding to my answer, here is how delegation with the new client look like:-

• In context of a GraphQL resolver

const resolvers = {
  Query: {
    users = (root, args, context, info) => {
      return prisma.$delegate.query.users(
        info,
      })
    }
  }
}

• Outside the context of a GraphQL resolver

prisma.$delegate.query.users(
  `{ id name }`,
})

• Also, note that it is possible to provide a selection set with the new client API, without using delegation

const fragment = `
fragment user on User {
  id
  name
}
`

const users = await prisma.users({}, fragment)

[beeplin]

Get it. Thank all you guys for the wonderful job:))

[schickling]

Update: Based on recent feedback we're about introduce a small API change for the fragment syntax:

Old

const result = await prisma.cats(
  {},
  `fragment Cat on Cat { id name favBrother { id } }`,
)

New

const result = await prisma
  .cats()
  .$fragment(`fragment Cat on Cat { id name favBrother { id } }`)

This solves the following problems:

• Problem with unintended auto-inferred generic arguments for TypeScript/Flow
• Confusion what happens when a fragment is provided in a non-terminating function chain call

[L-K-Mist]

@divyenduz trying to follow your solution for resolvers, but not getting anywhere. Got the latest prisma and client. Trying various permutations but keep getting Cannot read property 'query' of undefined.

I mean you've got root, args, context, info as arguments for your resolver, but then use prisma as the root of your return function.

Please, any guidance on any way to get nested list-data...

The closest result I've gotten so far was with:
In this case I get a good console.log ; but how then can I use this strange query in playground or apollo-client on the frontend?

  stalls: async (parent, args, ctx) => {
    const query = `
      query {
        stalls {
          image
          w3w
          lng
          lat
          name
          description
          owner {
            name
            id
          }
          markets {
            name
            province {
              name
            }
            id
          }
        }
      }
    `
    const result = await ctx.db.$graphql(query)

    console.log("​ctx.db.$graphql(query)", result)
    return result
  },

Okay, "TIME to step away from the computer and go to bed..."
:stuck_out_tongue_winking_eye: :laughing:

  stalls: async (parent, args, ctx, info) => {

    // console.log("​ctx.db.client.request(query)", ctx.db.client.request(query))
    const result = await ctx.db.$graphql(
       String(info) <---
    )
    // return ctx.db.client.request(query)
    console.log("​ctx.db.$graphql(query)", result)
    return result
  },

[L-K-Mist]

Woot! Solved it and the answer wasn't so bad:
Bring back Prisma Bindings just where you need them. Like in the prisma examples:
https://github.com/prisma/prisma-examples/blob/master/node-graphql-schema-delegation/src/index.js

Best of BOTH worlds, right?

Leaving this here for other Lost Boys.

[jangerhofer]

It appears that the repo @L-K-Mist linked has moved slightly to https://github.com/prisma/prisma-examples/tree/master/node/graphql-schema-delegation. The prisma-bindings library is the correct solution at the moment if you need to delegate an arbitrary query of subfields (often passed from the GraphQL client/consumer) to the Prisma backend, as Prisma Client (of approximately v1.18+) does not have the same ability.