Input validation with Ariadne

[upcFrost]

Hi,

What's the best practice of doing input validation with Ariadne. One of the threads mentions that directive-based validation is an anti-pattern, so I'd like to know what would be the correct way of doing it.

Example:

input MyInput {
  id: ID!
  notNegativeValue: Int!
}

For example, I know that the ID must be a valid uuid, and the nonNegativeValue is strictly non-negative. With directives, I can annotate both of them with smth like @validUuid, write a custom validation logic, and then it will be validated on any level regardless of how nested the input is. I can imagine one more way to be custom scalars but this would require extra integration on the frontend. Also it's possible to transform the input into pydantic BaseModel, but can be pretty slow.

Best regards,
Petr

[pkucmus]

My approach would be (and usually is) what you mentioned - custom scalars. Like a PositiveInt.

P.S. Could you link the mentioned thread? I'd like to catch up.

[rafalp]

My problem with custom scalars is that there is very little they can do, and a lot they can't, eg:

• read context
• hit database
• accept configuration (PositiveInt or Email look nice but StringShorterThan42Characters doesn't)
• work with 3rd party services and tools consuming schema without configuration

Run validation in resolver and return list of errors, like the docs say

[upcFrost]

Could you link the mentioned thread? I'd like to catch up.

#548

As the very first comment says, "the documentation is written to highlight best practices, and using directives for validation is not one of them" (written by @rafalp btw).

And I agree with him that custom scalars are definitely not a silver bullet, mostly due to p.3 and p.4 (not configurable, require extra headache for other tools).

Right now I'm using the codegen-only directive approach, i.e. directives which are not registered/implemented in the code and which are only used by the custom codegen to generate typed dicts validated via pydantic and to which inputs are resolved. It's not exactly ideal in terms of performance but it's flexible enough to cover all our current needs

Also I don't really agree with @rafalp about writing the simple (not complex, smth like x < 42) validation logic in the resolver, reason being that I would like to see the schema as a fully defined contract which I can show (not introspect but show the full thing) to anyone and it would be obvious to them what to expect from the call. Codegen-only directves allow this. What's more, with some dancing around the doc generation it's possible to read these directives from the schema and inject their values into the introspected doc which helps a lot.