You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Connector is a more direct connection to the db, but it doesn't use Vulcan "magic" and callbacks. They are internal to Vulcan and should not be used in user apps.
Mongoose models are ok for direct connection to the db, it's ok to use them but also won't run the callbacks.
Mutators will run Vulcan callbacks and permission checks, they are better suited for custom mutations.
We need an equivalent for queries, "Queriers". In particular, the querier should run permission check and remove unallowed fields.
Describe the solution you'd like
It should be as easy as possible to use a mutator. Namely, mutators can be either called in a mutation, in response to a request, or outside a mutation, so without a request (eg when seeding data) => both use cases should be handled correctly.
Normally, mutators do not depend on the request context, and should not use DataSources (they are only needed for field query resolvers, not for mutations), so the graphql context should not be a problem. It used to be an issue in Vulcan Meteor but that was because we used the GraphQL context wrongly.
Queriers are the equivalent for queries. They should fetch data correctly, and check permissions namely.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Connector is a more direct connection to the db, but it doesn't use Vulcan "magic" and callbacks. They are internal to Vulcan and should not be used in user apps.
Mongoose models are ok for direct connection to the db, it's ok to use them but also won't run the callbacks.
Mutators will run Vulcan callbacks and permission checks, they are better suited for custom mutations.
We need an equivalent for queries, "Queriers". In particular, the querier should run permission check and remove unallowed fields.
Describe the solution you'd like
Normally, mutators do not depend on the request context, and should not use DataSources (they are only needed for field query resolvers, not for mutations), so the graphql context should not be a problem. It used to be an issue in Vulcan Meteor but that was because we used the GraphQL context wrongly.
The text was updated successfully, but these errors were encountered: