Meteor method vs. deny/allow rules

by

Normally I try to avoid subjective answers, but this is a really important debate. First I’d recommend reading Meteor Methods vs Client-Side Operations from the Discover Meteor blog. Note that at Edthena we exclusively use methods for reasons which should become evident.

Methods

pro

  • Methods can correctly enforce schema and validation rules of arbitrary complexity without the need of an outside library. Side note – check is an excellent tool for validating the structure of your inputs.

  • Each method is a single source of truth in your application. If you create a ‘posts.insert’ method, you can easily ensure it is the only way in your app to insert posts.

con

  • Methods require an imperative style, and they tend to be verbose in relation to the number of validations required for an operation.

Client-side Operations

pro

  • allow/deny has a simple declarative style.

con

  • Validating schema and permissions on an update operation is infinitely hard. If you need to enforce a schema you’ll need to use an outside library like collection2. This reason alone should give you pause.

  • Modifications can be spread all over your application. Therefore, it may be tricky to identify why a particular database operation happened.

Summary

In my opinion, allow/deny is more aesthetically pleasing, however it’s fundamental weakness is in enforcing permissions (particularly on updates). I would recommend client-side operations in cases where:

  • Your codebase is relatively small – so it’s easy to grep for all instances where a particular modifier occurs.

  • You don’t have many developers – so you don’t need to all agree that there is one and only one way to insert into X collection.

  • You have simple permission rules – e.g. only the owner of a document can modify any aspect of it.

In my opinion, using client-side operations is a reasonable choice when building an MVP, but I’d switch to methods for all other situations.

update 2/22/15

Sashko Stubailo created a proposal to replace allow/deny with insert/update/remove methods.

update 6/1/16

The meteor guide takes the position that allow/deny should always be avoided.

More Related Contents:

  1. Average Aggregation Queries in Meteor
  2. How can I share MongoDB collections between Meteor apps?
  3. Problems to run examples in Meteor
  4. Build a reactive publication with additional fields in each document
  5. Meteor: difference between names for collections, variables, publications, and subscriptions?
  6. How to connect to external MongoDB instance in Meteor?
  7. How can I sort a Meteor collection by time of insertion?
  8. Meteor: uploading file from client to Mongo collection vs file system vs GridFS
  9. How to increment a field in mongodb?
  10. Is there a simple way to export the data from a meteor deployed app?
  11. Meteor: unexpected mongo exit code 100
  12. Find document with array that contains a specific value
  13. Update field in exact element array in MongoDB
  14. Mongodb sort inner array
  15. How to create a DB for MongoDB container on start up?
  16. MongoDB field order and document position change after update
  17. MongoDB Full and Partial Text Search
  18. How to enable authentication on MongoDB through Docker?
  19. Mongodb Join on _id field from String to ObjectId
  20. How do I do a “NOT IN” query in Mongo?
  21. How to efficiently perform “distinct” with multiple keys?
  22. Mongo, find through list of ids
  23. Difference between “id” and “_id” fields in MongoDB
  24. MongoDB nested array query
  25. Filtering embedded documents in MongoDB
  26. Is mongodb running?
  27. How to delete documents by query efficiently in mongo?
  28. Update embedded object inside array inside array in MongoDB
  29. How to check if an array field contains a unique value or another array in MongoDB?
  30. MongoDB index/RAM relationship

Leave a Comment