I think I don't like this new way of querying rela...
# orm-help
d
I think I don't like this new way of querying relation data Docs:
Copy code
// A `main` function so that we can use async/await
async function main() {

  // Read the previously created user from the database and print their posts to the console
  const postsByUser = await prisma
    .user({ email: "<mailto:bob@prisma.io|bob@prisma.io>" })
    .posts()
  console.log(`All posts by that user: ${JSON.stringify(postsByUser)}`)

}
What if i wanted to query the posts and something else like books. How would i do that? would it require two round trip requests
Copy code
const postsByUser = await prisma
    .user({ email: "<mailto:bob@prisma.io|bob@prisma.io>" })
    .posts()
const booksByUser = await prisma
    .user({ email: "<mailto:bob@prisma.io|bob@prisma.io>" })
    .books()
We loose the info way of only one query to get all data...
Copy code
{
    id
    posts {
       id
    }
   books {
     id
   }
}
fast parrot 1
๐Ÿ‘ 1
h
So stick to prisma-binding and schema delegation
๐Ÿ‘ 1
I just wish they made prisma-client complementary in the docs instead of overwriting the previous docs ๐Ÿ˜› I donโ€™t see myself using prisma-client anytime soon
๐Ÿ™ 1
๐Ÿ’ฏ 1
d
So i'm not missing anything. Just wanted to make sure. ty
โ€˜โ€™โ€™const mutation =
Copy code
mutation ($name: String!){
    createUser(name: $name) {
      id
    }
  }
const variables = { name: 'Alice' } const result = prisma.$graphql(mutation, variables)โ€™โ€™โ€™ This would work in my case native $graphql
g
I think, and I could be wrong, that using prisma-client abstract it from the top level to keep your queries & mutations simple. An interesting example is the โ€œviewerโ€ query + Resolver in the airbnb example: https://github.com/prisma/graphql-prisma-typescript/blob/master/src/resolvers/Query.ts#L43 https://github.com/prisma/graphql-prisma-typescript/blob/master/src/resolvers/Viewer.ts In you case, you could do:
Copy code
# query/user.js
async function me(_, args, context) {
  const id = await getUserId(context);

  return context.prisma.user({ id });
}
& then, in your resolvers:
Copy code
...

User: {
    books(root, args, context) {
      return context.prisma.user({ id: root.id }).books();
    },
    posts(root, args, context) {
      return context.prisma.user({ id: root.id }).posts();
    },
  },
But I agree, schema delegation is way more simple
d
You can also use the
$fragment
syntax to achieve this result and have better type safety than schema delegation https://www.prisma.io/docs/prisma-client/basic-data-access/reading-data-TYPESCRIPT-rsc3/#using-fragments-for-fine-grained-data-access What do you think about it?
๐Ÿ‘ 1