I’ve tried a boilerplate from

prisma examples

and

graphql-boilerplates

repos and they all work differently

@nikolasburk none of

prisma-examples

import schema from

./generated/prisma.graphql

(cause it’s not generated through graphql-cli) and duplicate types instead. Is it really the best practice? I want to share certain schemas between prisma and yoga.

Let me know if that helps 🙂

I had a look at

graphql-schema-delegation

example and it’s probably what I’m most after at the moment since the API is tightly coupled with Prisma, however, I don’t like the DX of lack of type safety. I’m not sure how to implement a hybrid setup that uses

graphqlgen

(with all type definitions) while delegating parts of the schema to Prisma directly. I don’t want to expose the full Prisma schema either so I’m not sure if

graphql-import

helps here? I essentially don’t want to write resolvers for each type and non-scalar field as this would end up in loads of boilerplate-like code, such as:

import { UserResolvers } from '../generated/graphqlgen'

export const User: UserResolvers.Type = {
  ...UserResolvers.defaultResolvers,

  permissions: (parent, args, ctx) =>
    ctx.prisma.user({ id: parent.id }).permissions()
}

Any thoughts @nikolasburk?

Also note that we're aware that none of the solutions is ideal if you just want to expose a few Prisma operations through your own application server, we're already working on tooling that further improve the workflows here!

@nikolasburk I’ve noticed that the typescript schema-delegation example has been removed from the repo. I’m currently following typescript-advanced boilerplate from https://github.com/graphql-boilerplates/typescript-graphql-server/tree/master/advanced. Is it still the recommended way of using Prisma bindings?