How do fragment replacements (used with prisma-binding) work with Prisma 2?

This question was asked by a community member and I'm relaying it here myself so others can see how to deal with these situations.

Let's say the following query is sent by the client:

query {
  users(where: {status: active}) {
    name
    photos(where: {category: Holiday}) {
      tags {
       code
      }
      attachment(size: 1024) {
        url
        contentLength
        contentType
      }
    }
  }
}

Let's imagine the "attachment" type is NOT part of the database schema and gets generated on the fly.

When using prisma-binding in the resolver, I could do something like that:

const Photo = {
  attachment: {
    fragment: `fragment AttachmentOnPhoto on Photo {s3Url tags {name}}`,
    resolve: (photo, args, ctx, info) => {
       return ctx.makeAttachment(photo.s3Url, photo.tags, args.size);
    }
  }
}

This way I can use a fragment to avoid another round-trip to Prisma if I wanted to fetch "s3Url" and "tags.name" which is needed to resolve this node.

If I were to use Prisma 2, I would probably need to:

const Photo = {
  attachment: ({id}, args, ctx, info) => {
     const photo = await ctx.client.getPhoto({where: {id}).include({s3Url: true, tags: {name: true}});
     return ctx.makeAttachment(photo.s3Url, photo.tags, args.size);
  }
}

This way there's another trip to the database needed because I cannot tell my parent what data-dependencies I have. What are your thoughts on that?

prisma / p1-to-p2-upgrade-path-feedback

How do fragment replacements (used with prisma-binding) work with Prisma 2? #10