Input argument validation

Schema Design
21

Nice!

I also want to improve my own validateDateRange directive. I need to check what happens in queries where the input is used in fields that aren’t at the root level.

1 Like
22

I’m back with updates!

My previous implementation wasn’t working quite as expected, especially with nested fields. In those cases, the parent resolver was executed before input validation occurred in the nested fields, which wasn’t ideal for me. I want to validate all inputs first, regardless of whether they’re placed in nested fields or at the root, and only then execute the resolvers.

After experimenting, I found a better approach:
I’m still using mapSchema to attach metadata, and I moved the validation logic into an Apollo Plugin, specifically in the requestDidStart => didResolveOperation lifecycle.

Why not MapperKind.OBJECT_FIELD or INPUT_OBJECT_FIELD?
Well…

  • OBJECT_FIELD: Runs the logic on every field, which technically works, but it means validating inputs multiple times per request. I don’t want this.
    Instead, it’s cleaner and more efficient to iterate through arguments just once at the beginning of the request via requestDidStart.
  • INPUT_OBJECT_FIELD: it’s not possible to get data from both field at same time (start and end) and do the comparison. Each execution is independent.

I tried using reflect-metadata to create the metadata, but the fieldConfig reference was different between mapSchema and the Apollo Plugin. I’m not sure why, but Reflect.getMetadata was returning undefined, then I created my own metadata class using Map of Map

3 Likes
23

Now we’re using our big brains. That’s awesome!!

Are you going to open source your plugin/solution (asking for me :joy:)? I’d like to give it a try and/or contribute if possible.