Server pluggable methods (meteor methods equivalent)

[BrianRosamilia]

Security with client side updates can get incredibly complicated when allowing client side queries. See the difficulty Meteor has gone through here :

https://www.discovermeteor.com/blog/allow-deny-challenge-results/

The recommended way to handle production security is to use Meteor methods.

I believe this would solve a multiple issues. Considering there is no schema support, it would be welcomed to use thinky + horizon methods for update/create/delete security while using the declarative method for read security.

Note : this would miss out on optimistic ui unless a great deal of other work/changes were done

[deontologician]

We've gone a slightly different route in Horizon, where direct queries are allowed only where they're explicitly turned on by the permissions system (see http://horizon.io/docs/permissions/), rather than making you throw out the convenient query system once you're ready to go to production.

That said, custom endpoint are something we want to do: #337

Do you think there is an aspect of this that's not covered by another issue at the moment?

[BrianRosamilia]

I still think people will be asking for custom methods shortly. Hear me out :)

An example from that page

[groups.authenticated.rules.store_message]
template = "collection('messages').replace({id: any(), counter: any()})"
# The counter can only be incremented by one step at a time
validator = """
  (context, oldValue, newValue) => {
    return newValue.counter == oldValue.counter + 1;
  }
"""

Now imagine you want to be able to update other fields on that document but not increment the counter, the logic becomes

[groups.authenticated.rules.store_message]
template = "collection('messages').replace({id: any(), counter: any()})"
# The counter can only be incremented by one step at a time
validator = """
  (context, oldValue, newValue) => {
    return (newValue.counter == oldValue.counter + 1 || newValue.counter == oldValue.counter) && typeof newValue.message === 'string';
  }
"""

Once you begin having to validate multiple fields for separate pieces of logic, this kind of validation becomes clunky. Having a separate method for increment the counter and changing the message seems like a logical way to break the problem into pieces.

#337 is still incompatible with other libraries server-side. Being compatible with them is an attractive idea. The lack of external i/o in validators also prohibits things like logging.

I'm not saying this needs to be super high priority, I just think it would satisfy a great deal of other use cases and allow people to choose a simpler project structure 👍 In my opinion, once more serious horizon applications are made, this will come up

[deontologician]

Ok, I'll leave this open to explore the idea. I think we may end up solving some of these problems using #138 but it's not clear all use cases will be handled by the other mechanisms

[deontologician]

I think most everything here will be covered by the plugins functionality (#373) see the RFC in #588