Open eric-burel opened 3 years ago
After more investigation:
DataSources and connectors will be soon better supported. The "queriers" might reuse the "createContext" method to generate a valid graphql context internally. They probably should not use the "dataSources", but only the connector of the model.
/!\ Right now the default connector (Mongo) is added in "api/graphql.ts" => we should figure a way to provide a helper in "@vulcanjs/mongo-apollo" to create models that directly have this connector?
Is your feature request related to a problem? Please describe. The connector is meant for database communication, as an ORM. But it cannot include Vulcan security checks. Describe the solution you'd like
user
API route: it doesn't respect permissions because its bypassing permission filtering. Mutators/queriers are the default way to get standard data, connector should only be used for custom mutations/resolverscreateMutator({ model: Users,...})
becomesUsers.create = (params) => createMutator({model: Users, ...params})
. Same goes for hooks by the way (useMulti<UserType>({model: "Users"})
=>useMultiUsers(...)
.Describe alternatives you've considered Putting callbacks within the connector, at the db level. But that will never be sufficient, as the connector is always specific to the underlying technology. Mutators are the right place to do "generic" checks, like checking Vulcan permissions.
Connector should only be used when creating a custom mutation/resolver, that do not fit the basic crud operations.
For instance, see account management feature: we use the UserConnector, and StorableTokenConnector => we should use "queriers" and "mutators" instead so that callbacks are correctly applied.