Why use Collection.allow instead of just Meteor.methods and Meteor.call to those methods?

Question

Running through the basic Parties Meteor example (http://meteor.com/examples/parties),

I am wondering why you would need to ever use Collection.allow to specify which inserts,updates,etc... go through instead of just using Meteor.methods and then issue Meteor.call from the client.

Seems that the "methods" way is always better since its more flexible (i.e custom functions)

Answer 1

The allow and deny interface is flexible enough for most access control that you would want. If you can use the built-ins, you end up with cleaner, more understandable, more readable code. It's also more Meteoric, in that it preserves Meteor's "database-everywhere" abstraction of being able to perform database operations directly on the client.

It's possible to deny all operations on your collections and then only expose access to the collections through methods. But there's a good chance you'd end up re-implementing a CRUD interface anyway, and you'd probably end up re-implementing the allow and deny functions.

I try to only use Meteor.methods if I find it difficult to express the access control I need through the allow and deny interface. For example, there are times when you need to update two related collections at once and the validation needs to examine the proposed changes to both collections before determining if the operation should proceed. That's cleaner with a Meteor.method.