Are there any hooks to validate the data for a type (not a field) before resolving it?

[ingluisjimenez]

I have an API where multiple fields resolve to a User ObjectType or a list of Users and there are certain application business rules where a User should not be returned, like when there is an authenticated request and the authenticated user should not be able to see the user they are requesting, because they have been blocked or any other logic. Similar to this, there could be other conditions where the API shouldn't return a User.

While I understand that this logic is business logic and should be specific to the application/data retrieval layer, I am wondering if the graphql-php library provides a hook to inject a callable to filter out the data that is passed down to a given Type and prevent the type from "resolving" and attempt to resolve any of the User fields in this case?

I have thought about achieving this using middleware, but this would be required to be applied on every single field where I am returning a User or a list of Users. A similar approach would be to manually call a filter function before finishing resolving any field that would return a User or a list of User, but the goal would be to define this logic in a single place and have the GraphQL server call this filter function before passing control to the User ObjectType, and only call it if it is not filtered by the function.

[spawnia]

The only way you can influence the behaviour is through resolvers, either the one of the field returning the User (or list thereof), or the ones for the fields on that User type.

[ingluisjimenez]

@spawnia thank you for your answer and all the time you dedicate to maintaining this library.

I was afraid of this being the case, but definitely understand these are different concerns and it is up to the application to guard and ensure a resolver is not returning values when it shouldn't. What I am trying to achieve is to have a single place with the logic to filter, but more importantly, remove the need to remember about filtering everywhere we return a User or a list of Users.

Wonder if you would be open to exposing a way to configure a callable that would be called after resolving a given type and right before passing control down to the type's fields. Not sure if that is possible based on the current implementation details of the library, but I wonder if it would be something that you'd be interested in.

[spawnia]

I see how something like that could be done on a technical level. Basically, listen to a lifecycle event like ManipulateSchema, walk the schema and attach a field middleware to every field returning a certain type.

Seems niche though, not looking to add this as a feature.

[spawnia]

Just realized, my answer only makes sense when using Lighthouse.

[ingluisjimenez]

No worries. I understand this might not be something within the scope of this library and the fact we can apply middleware could be the preferred approach for this type of feature.

I was hoping there was a way to define this hook/callable in one place and have it automatically called by the framework without having to apply the middleware on every case, but this is not a huge concern.

[shmax]

I don't know if this is exactly what you're looking for, but maybe it will give you some ideas:
https://github.com/shmax/graphql-php-validation-toolkit

[ingluisjimenez]

Thank you for the link @shmax. That library is focused more on validating the inputs/args, but what I am referring to is an additional layer or validation/filtering for the data that a resolver returns for a given type.

i.e Your resolver returns a user but you still need to make sure that everywhere where you are returning a user (or a list of users), that user meets X criteria.

I plan to do this using middleware and adding the middleware to every field that returns an User type or a list of Users, but I was hoping there was a way to define this hook/callable in one place and have it automatically called by the framework.

[shmax]

Sure, I understand, but you may find that you could make a library similar to mine that does the validation (or filtering) on the outgoing data rather than the incoming args.