Resolver that fires meteor method? Or act directly on Meteor Collection?

apollo
1

Would you do something like this?

// ROOT QUERY
// ========================
const RootQuery = new GraphQLObjectType({
	name: 'RootQueryType',
	fields: {
		user: {
			type: UserType,
			args: { id: { type: GraphQLString } },
			resolve(parentValue, args) {
				return Meteor.call('getUser');
			}
		},
		company: {
			type: CompanyType,
			args: { id: { type: GraphQLString } },
			resolve(parentValue, args) {
				return Meteor.call('getCompany');
			}
		}
	}
});

or

// ROOT QUERY
// ========================
const RootQuery = new GraphQLObjectType({
	name: 'RootQueryType',
	fields: {
		user: {
			type: UserType,
			args: { id: { type: GraphQLString } },
			resolve(parentValue, args) {
				return Meteor.users.findOne({_id: this.userId});
			}
		},
		company: {
			type: CompanyType,
			args: { id: { type: GraphQLString } },
			resolve(parentValue, args) {
				return Companies.findOne({_id: args._id});
			}
		}
	}
});

Is there an upside or downside to either or?

and a follow up, are folks using simple-schema still or just relying on the mutation schema to allow/deny accordingly? I suppose you can avoid using simple-schema on smaller apps where Mongo is your main data store?

2

Shame that this question never got a reply, am starting out with Apollo and Meteor and wondering the same thing - I’m thinking that there is probably no need for the Meteor method but it would be good to hear the views of more experienced users!

1 Like
3

After using it for awhile, I’d probably act directly on the collections (or helper functions you create). I don’t recall any downside to meteor methods… but it was also a long time ago.

1 Like