Approach to mutation payloads and prisma fields

[giraugh]

Intrigued what peoples approaches are to this problem. I have various mutations that return usually 1 but occasionally several different prisma types wrapped in a payload type. The problem being that these payloads are not themselves types in prisma and so can't be returned from a prisma field (using prismaField or prismaFieldWithInput). This isn't a big deal but the problem I've faced is when the mutation represents a "delete" action, pothos attempts to fetch the fields in the payload directly from prisma which dont exist anymore, throwing an error.

Here is a concrete example. If we have a deleteUser mutation defined like this

builder.mutationFields(t => ({
  deleteUser: t.fieldWithInput({
    type: UserPayloadRef,
    input: {
      id: t.input.id({ required: true }),
    },
    resolve: async (_, { input: { id } }) =>
      prisma.user.delete({
        where: {
          id,
        }
      })
        .then(user => ({ user }))
  })
})

which returns a payload defined like so

interface UserPayload { user: PrismaUser }
const UserPayloadRef = builder.objectRef<UserPayload>('UserPayload').implement({
  fields: t => ({
    user: t.expose('user', { type: UserRef })
  })
})

then performing this mutation

deleteUser(id: "someid") {
  # UserPayload
  user {
    # User
    posts {
      # Some nested field on the user
      # ...
    }
  }
}

will throw an error because a prisma.user.findUnique call is performed with the result of the mutation which will fail because the user was already deleted.

Hoping that made sense 😅 I feel like I might be missing something obvious here. Any thoughts?

[hayes]

Nothing obvious here. This is a hard problem in GraphQL. Generally mutations happen in the root resolvers, and the rest of the query tree ends up being resolved asynchronously after.

Being able to query into something that has just been deleted is probably a pattern that will cause a lot of pain. I would recommend not returning the deleted items in your mutation.

That being said, a potential option would be to create your UserPayload as a "variant" of the User type, and have the user field implemented using the t.variant method. (see https://pothos-graphql.dev/docs/plugins/prisma#type-variants).

You mutation can then be a prismaField that returns the payload variant, and will receive a query argument. You can use this to do a select that grabs all the nested selections before deleting.

This would work for most basic cases, but there are a bunch of edge cases where this might still fail (if you can't resolve everything in one query), and it's possible there are some nested on your deleted object that have their own resolvers that may not work after the user is deleted. So the above is a workaround that may work for you, but I'd still recommend avoiding it if possible.