Now we(Prisma community) have generators for Joi, Yup and even Class Validator! I have just published the last one a few minutes ago. You can check them out here: https://github.com/omar-dulaimi/prisma-joi-generator https://github.com/omar-dulaimi/prisma-yup-generator https://github.com/omar-dulaimi/prisma-class-validator-generator

Thanks for sharing it~! This looks so cool! Will there be any use-case for GraphQL users? I’m curious if graphQL covers all the above avoiding impedence mismatching.

Hey @Hyo thanks for motivation, it helps As a matter of fact, I have used Joi with a graphql server, validations took place through a decorator named anything like "@Validate(SchemaName)", so it should work fine. Yup is inspired by Joi and have frontend support, so it should work fine too. If you use Graphql through a tool like typegraphql-prisma that handles the generation of resolvers, then you're not going to need the class validator generator; since typegraphql-prisma outputs models by default. The only thing you miss would be the validations from class validator. Which can be painful to manually do if you have a big schema. And finally, since prisma generators rely on the dmmf generated by prisma itself, then you can expect to get as much as prisma exposes. Hope I answered your question.

Any preference between Yup and Joi? I've only used Yup and like it but wondering if Joi is a better option.

Yup was actually inspired by Joi, and works everywhere. Joi however is more intended for backend validations. Also I noticed that Yup doesn't support everything Joi support out of the box, sometimes you have to write them on your own with

addMethod,

for example, I had to write a

oneOfSchemas

method to replicate the Joi alternatives functionality. So for me, I would use Yup on the frontend only, since it already plays well with other frontend libraries like formik. And I would stick to Joi on the backend. You have a second option for the backend by the way, which is class validator, and it's really cool.

Any plans for Zod? Seems to have better TypeScript support.

Now there is. Thank you for bringing it up to my attention. I'll work on it soon

@Omar thanks, trying to figure out how important it is to do this type of validation on top of the validation done by our GraphQL API, which is obviously just limited to fields being required or not and certain basic data types.

@Chris Tsongas I noticed that

zod-prisma

generates just the base models as they are described in the prisma model; not really full CRUD schemas for all actions a schema can provide. So there might be still a need for me to build that generator, similar to yup and joi.

Zod does seem like the best fit for Prisma does it not, given its more advanced TS support?

Yes, indeed. I see it taking over the validation scene on both fronted and backend very soon.

@Omar do you know of any resources specific to Apollo Server? I'm already using GraphQL Code Generator, Apollo Server, and GraphQL Scalars, and am trying to figure out whether and where to implement JSON schema validation. Not using decorators anywhere and want to avoid those (tried TypeGraphQL but stopped using it immediately when I saw it generated over a quarter million lines of code for our project).

There's an awesome list already: https://github.com/ooade/awesome-apollo-graphql And regarding JSON schema validation, could you explain more what your use-case is? Since you brought up decorators, you could use an express middleware instead, you have to use apollo-server-express though. TypeGraphQL-prisma plugin allows to pick what to generate; so you could generate models only for example, which a lot less code

I think the use case is to enforce business logic, Apollo Server handles things like making sure required fields are present and checking data types, but things like making sure a start date is before an end date need additional validation. Seems like the easiest place to do that would be in my resolvers, rather than setting something up with middleware (I am using apollo-server-express because we have some webhooks endpoints).

Honestly, I think you should do it with a decorator, just one. And the top of every query/mutation/endpoint you write the name of the decorator and pass the schema to it as an argument like this:

@Validate(CreatePostSchema)

Inside the Validate decorator, you simply run schema.validate() or similar, like schema.parse in case of zod. This way, you remove validation logic from inside of resolvers, which makes them cleaner and more readable.