Prisma utils plugin feedback

[hayes]

I just published the initial version of a new plugin to start supporting some use-cases for tighter prisma integration with Pothos.

So far the prisma plugin has been purely focused on defining output types, fields, and relations. This adds a lot of value, but there are a lot of use-cases that require a non-trivial amount of manual work around inputs.

The prisma-utils plugin is meant to start provide helpers to simplify that process.

The initial version is focused on creating input types for filtering and ordering lists of prisma objects.

If you have been looking for ways to simplify the process of creating input types, I would love to get some feedback on this initial version.

Very limited docs are available here: https://github.com/hayes/pothos/tree/main/packages/plugin-prisma-utils

The example at the bottom is meant as an example of the kind of tools that could be created either internally for your app, or published as a community maintained package. The implementation is hopefully simple enough to understand and customize to your own needs.

In the future I would like to add more utils to make those generator scripts even simpler.

[hayes]

If you are trying this out (or avoiding it because it doesn't support your use case). I'd love to hear how you are using it, and how you are structuring your input types. Specifically I'd love to know what patterns you want/expect for filters (This initial version is closely modeled on prisma API, but would love to see other ways of doing this).

Other things I'd be currious to know about are patterns/requests/requirements for non-list fields, or anything else thats missing. Input types for creating/updating/deleting are obviously not supported yet, but if you have specific examples of patterns that you like for this, that could also be valuable to share here.

[ricardo-valero]

One thing I recently noticed when using your example generator is that it is missing prisma's AND and OR in the where filter... will look for a way to include it

[hayes]

I'll look at adding these in the next version!

[ricardo-valero]

I've seen this used with trpc + zod + prisma
https://github.com/omar-dulaimi/prisma-zod-generator

Would it be possible for zod input types and to seamlessly work with pothos? 🤞

[hayes]

The types created by this plugin can be passed directly to Prisma, meaning that they should also be compatible with these zod validators. Is there some additional integration you are looking for, or issues you ran I to when trying this out?

[ricardo-valero]

Hm I just looked through it, still waiting on the mutation input types (create, update, delete). I was using this #346 for my where and orderBy inputs.

One pain point of my current setup is that I can't keep up with the changes of my db schema and my mutation input types.

For example, renaming some column in my db

model Vehicle {
  archived Boolean @default(false)
  id       String  @id @default(cuid())
  plate    String  @unique
  type     String?
- model    String?
+ year     String?
  brand    String?
}

won't show up an error in my input type

const VehicleCreateInput = builder.inputRef<Prisma.VehicleCreateInput>('VehicleCreateInput')
  .implement({
    fields: t => ({
      plate: t.string({ required: true }),
      type: t.string(),
      model: t.string(), // should expect an error?
      brand: t.string(),
    }),
  })

[ricardo-valero]

Maybe this wasn't the place but I'm looking for something like this but for pothos
colinhacks/zod#973 (comment)

[hayes]

Haven't gotten around to inputs for mutations yet. They get complicated quickly with relations, but could probably get something together for scalar fields pretty soon.

[hayes]

added mutations (see comment below), I know it's been a few months, but hopefully this is still relevant

[ricardo-valero]

How would you prevent null in args

builder.queryField('companies', t =>
  t.prismaField({
    type: ['Company'],
    args: prismaArgs.Company,
    resolve: async(query, root, args, { prisma }) =>
      prisma.company.findMany({
        ...query,
        ...args,
      }),
  }),
)

Type 'null' is not assignable to type 'CompanyWhereInput | undefined'.

[hayes]

See the example here: #544 (comment)

where: args.where ?? undefined. I'd generally advise against spreading args into a query directly.

[ricardo-valero]

Thanks for the advice, but why is that?

[hayes]

This is just how graphql works. Basically in graphql, for a nullable argument or input field, you can either omit the value entirely, or you can pass null explicitly. This also applies to nullable fields with default values, you can still pass null explicitly which will overwrite the default value. For the fields on the input types created by the prisma plugin, we map the values in the inputs to strip out nulls, but for arguments that return those types, we don't. This is mostly just because so far the utils only know about the fields inside the input types, and not about arguments that happen to be prisma utils types. We could probably apply the same transform to any arguments that happen to return a type created by the prisma utils package, but this isn't implemented yet, and I'd have to think through if this always makes sense to do.

[LawJolla]

Thanks @hayes for your incredible love and passion for your library and the community generally.

If I can help make this a reality, please let me know. I'm an app developer that's always scared of libraries and doesn't feel smart enough to help but I need to get over my irrational fear and contribute back.

I've been in the GraphQL space since 2016 and thought the original nexus-prisma plugin was the high water mark for auto gen CRUD.

For example...

const User = prismaObjectType({
  name: 'User',
  definition(t) {
    t.prismaFields(['id', 'name', 'posts'])
  },
})

const Mutation = prismaObjectType({
  name: 'Mutation',
  definition(t) {
    t.prismaFields(['createUser', 'updateUser', 'deleteUser', 'deletePost'])
    t.field('createDraft', {
      type: 'Post',
      args: {
        title: stringArg(),
        content: stringArg({ nullable: true }),
      },
      resolve: (parent, { title, content }, ctx) => {
        return ctx.prisma.createPost({ title, content })
      },
    })
  ...
})

See more at: https://www.prisma.io/blog/using-graphql-nexus-with-a-database-pmyl3660ncst

The big pain points for autogen and pothos now there where, orderBy, and data for create and update mutations.

I think the helpers you've already done get 99% of the way there for queries. Here's an example where I converted Nexus + Nexus-Prisma to Pothos

export const vendors = extendType({
  type: "Query",
  definition(t) {
    t.crud.vendors({
      pagination: true,
      filtering: true,
      ordering: true
    })
  }
})

const PrismaInputArgs = pothosArgsForPrismaTypes(builder, ["Vendor"])

const VendorsInput = builder.inputType("VendorsInput", {
  fields: (t) => ({
    where: t.field({ type: PrismaInputArgs.Vendor.where, required: false }),
    order: t.field({ type: PrismaInputArgs.Vendor.orderBy, required: false }),
    take: t.int({ required: false })
  })
})

builder.queryFields((t) => ({
  vendors: t.prismaField({
    type: ["Vendor"],
    nullable: true,
    args: {
      input: t.arg({ type: VendorsInput, required: true })
    },
    resolve: async (query, __, args, ctx) => {
      try {
        const { where, order, take } = args.input

        const result = await ctx.prisma.vendor.findMany({
          ...query,
          take: take ?? undefined,
          where: where ?? undefined,
          orderBy: order ?? undefined
        })
        return result
      } catch (e) {
        if (e instanceof Error) {
          throw new Error(`[vendors] ${e.message}`)
        }
        throw new Error(`[vendors] ${JSON.stringify(e)}`)
      }
    }
  })
}))

That's a pretty straight forward solution without too much pain. Mutations are still problematic though with a lack of data typing e.g.

import { builder } from "../lib/pothosBuilder"
import { pothosArgsForPrismaTypes, Prisma } from "@wk/prisma2"

const PrismaInputArgs = pothosArgsForPrismaTypes(builder, ["Deal"])

// what to do here for data?
type Data =
  | (Prisma.Without<Prisma.DealUpdateInput, Prisma.DealUncheckedUpdateInput> &
      Prisma.DealUncheckedUpdateInput)
  | (Prisma.Without<Prisma.DealUncheckedUpdateInput, Prisma.DealUpdateInput> &
      Prisma.DealUpdateInput)

// is it possible to build this without Implement?
const Data2 = builder.inputRef<Data>("Data").implement({
  fields: (t) => ({
    id: t.string({ required: false }),
   ...
  })
})

builder.mutationField("updateDeal", (t) =>
  t.prismaField({
    type: "Deal",
    nullable: true,
    args: {
      where: t.arg({ type: PrismaInputArgs.Deal.where }),
      data: t.arg({ type: Data2 })
    },
    resolve: async (query, root, args, ctx) => {
      return ctx.prisma.deal.update({
        ...query,
        where: args.where ?? undefined,
        data: args.data ?? undefined
      })
    }
  })
)
export const updateDeal = extendType({
  type: "Mutation",
  definition(t) {
    t.crud.updateOneDeal({
      alias: "updateDeal"
    })
  }
})

The only issues I've run into is duplication of types, e.g. Vendor will have a VendorOrderBy for the query and mutation, and exposing the enums. Since the same Enum will be in multiple objects, I expose them up front..

  P.Prisma.dmmf.datamodel.models.forEach((model) =>
    model.fields.forEach((field) => {
      if (field.kind === "enum") {
        const cache = getCache(b)
        if (!cache.has(field.type)) {
          const EnumRef = b.enumType(
            (P as unknown as Record<string, BaseEnum>)[field.type],
            {
              name: field.type
            }
          )
          cache.set(field.type, EnumRef)
        }
      }
    })
  )

[hayes]

just shared an update on this below, hopefully that will work for your use case

[hayes]

Some updates for anyone following this discussion:

I spent some time the last couple days implementing support for mutation types in the prisma-utils plugin. It doesn't cover everything yet, but it should be a great start for anyone trying to quickly build crud apps with pothos and prisma.

What's being added

• WhereUniq inputs
• Create inputs
  • allows creating Create objects for any prisma model
  • Creates for nested relations
    • relations are implemented use an intermediate object (like prisma) that support create and connect
    • connectOrCreate is not supported yet
• Update inputs
  • allows creating Update objects for any prisma model
  • Updates for nested relations
    • relations are implemented use an intermediate object (like prisma) that support the following operations
    • create
    • update
    • connect
    • delete
    • disconnect
    • set
    • upsert and connectOrCreate are not supported yet
• Example Generator
  • The example generator was re-written and is now a bit different
  • It now supports Unique filters, as well as Create and Update inputs

This change has not been merged, but a preview release is available, and I would really love any feedback.

If you are interested in this topic, and have some time, please try it out: #703

I haven't gotten much actionable feedback outside of asking for support for mutations, so hopefully this will unblock some people from giving it a try

[hayes]

If you are tying this out, let me know here or on the pothos discord, I am more than happy to help get you set up to try this out. This kind of project is really hard to move forward without feedback (especially since this is not particularly useful for my own use cases). I really want to create something that solves the issues people have been having, but haven't been able to get enough feedback to be confident in the current direction.

[dantrain]

I hope to try this out soon and provide feedback. Thanks so much for your efforts.

[thuperthecret2]

Coming from Prisma1 it generated every possible thing in the schema that you could think of (types, create inputs, createMany inputs, update inputs, updateMany inputs, where inputs (including AND/OR/NOT, in, not_in, lt, lte, gt, gte, contains, not_contains, starts_with, not_starts_with), orderBy inputs, subscription payloads, subscription previous values, AND/OR/NOT, connections, edges, nested/related table concurrent-create inputs, createMany inputs) and then you could pick and choose or copy/paste/modify whatever you needed from it or choose to leave it all in the schema. I simply chose the ones I needed and used those and it saved me loads of time. My old prisma.graphql autogenerated file is 10500 lines long so I have quite a few inputs to create. My project has 27 tables, 105 queries and 11 enums, that's a lot to convert manually! Maybe there's some inspiration to be found for you in looking at some Prisma1 generator source code, because having all that info there is VERY helpful to understand prisma and its power, and to take advantage of it.

I noticed in the readme it says "the goal is not to generate all input types automatically" but having a generated file with all possible types was very valuable to me in the past, so maybe that can be an option in the generator to create an "everything" output file just for reference (but not have everything in the actual schema except the bits and pieces one needs for their schema).

As soon as I get a chance to play with this I'll provide feedback. Thanks for so much work on a very cool package, I'm quite glad I found Pothos.

[hayes]

After a long delay, a new version of this plugin was finally published! Check it out https://pothos-graphql.dev/docs/plugins/prisma-utils and let me know what you think!

[cinan]

so far, it works quite well! We're using primarly prismaWhere, prismaCreate, prismaCreateRelation and prismaUpdate . Also I've generated input types with static generator for large tables. It surely saved a lot manual work!

Currently I'm struggling with writing connectOrCreate relation, which is missing in API :(

Also, prismaCreate is missing some required: true flags.

[forcemagic]

Hi @hayes ! Thank you for your effort in making this plugin possible! 🙌
Is there any way to create input types for createMany operations? It seems like NOT NULL relations need to be connected via their FKeyed field, but adding that field to builder.prismaCreate doesn't help much and Prisma still throws a type error. 😔

Example code here

export const MyCreateInput = builder.prismaCreate("MyModel", {
  name: "MyCreateInput",
  fields: () => ({
    myRelationId: "String",
  }),
});

t.field({
  ...
  args: {
    data: t.arg({ type: [MyCreateInput], required: true }),
  },
  resolve: async (_p, { data }) => db.myModel.createMany({
    data, // this throws typeerror: Property 'myRelationId' is missing in type 'MyCreateInput' but required in type 'MyModelCreateManyInput'
  }),
});

Casting doesn't help as it throws the same error. Explicitly specifying this field (via builder.inputRef<Prisma.MyModelCreateManyInput>().implement({ ... })) works.

Are there any plans for implementing this? Thanks in advance! 🚀

Versions

@pothos/plugin-prisma@npm:3.51.1
@pothos/plugin-prisma-utils@npm:0.8.1
@prisma/client@npm:4.15.0

[hayes]

can confirm this is currently broken.

There are 2 ways I could seeing this work:

• Update the prismaCreate method to properly allow setting a relation via it's corresponding ID field (as you pointed out, this doesn't work, but prisma supports it for both create/createMany.
  • this would mean that you need to be careful about what fields you include when you create the input type if you want to use it for both create and createMany
• Add a separate prismaCreateMany method to create updateMany specific inputs
  • This makes the graphql schema slightly more complicated, because you would end up with 2 mostly identical input types

I am leaning towards the first option, but the implementation here is a little complex, and not sure how hard it would be to make it work correctly