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.
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.