Possible future of cancan

I’d like to suggest possible future of cancan:

• make API a bit simpler (ability.can('read', Post) instead of can(user, 'read', Post))
• improve performance of checks via special datastructure (this will prevent event loop blocking in case of big amount of rules)
• provide more sophisticated rule checks based on Mongo QL (can be added with help of sift.js)
• create a mongoose middleware which converts specified rules into Mongo Query and allows fetch records like Post.accessibleBy(ability), where ability is a configured instance of Ability class which in this library is just called CanCan
• separate RuleBuilder and Ability this will allow to build context dependent DSL

const { RuleBuilder, Ability } = require('cancan')

function defineRulesFor(user) {
  const { can, cannot } = new RuleBuilder()

  can(['read', 'update'], 'Post');
  can('delete', 'Post', { createdBy: user.id });
  cannot('update', 'Post', { readonly: true });
  can('read', 'Comment');
  can('delete', 'Comment', { createdAt: { $gt: Date.now() - 3600 * 1000 } })

  return can.rules;
}

const ability = new Ability(defineRulesFor(currentUser))

ability.can('read', Post)

• more tests (also I’d like to use something like mocha or jest for testing)
• provide browser version of the library
• add better documentation (similar to what Ruby cancan has, provide examples for Express.js integration, for Angular2/Aurelia/Ionic2/React/Vue integration)

Some of these I did in past, so instead of creating one more cancan project suggest to merge some of my ideas into yours 😃 So, @vadimdemedes what do you think?

[stalniy]

Please check https://github.com/stalniy/casl in case if you are interested to see what I came up with

[vadimdemedes]

Thanks for putting all these suggestions too. Too bad that it’s not a good fit, in my opinion. Good luck with your project!