Order of @auth directive Processing

Hi,

Thanks for such a detailed question.

There’s no sense of FIFO ordering because for example ‘and’ rules find subsets of nodes you can see, so we still have to process all the rules.

Here’s how the rules are processed.

  • we process all the RBAC style rules first (the ones that look like this "$USERROLE: {eq: \"ADMIN\" }" if from that we can evaluate the auth, then we stop there and never go to the DB. For example, in your rule you have or: [ A, B, {rule: "$USERROLE: {eq: \"ADMIN\" }"} if the JWT says they are the admin, we can stop without evaluating anything else. Similarly, for the nested cases, we can cut out evaluation of other rules.
  • after we have evaluated all the RBAC rules, we then run any remaining database rules in parallel.

So the ordering doesn’t matter.

For, your second question, we are looking at adding some ‘default’ values and custom computation for the 20.11.0 release, so you’ll be able to add the kind of ‘now’ you are talking about and have it auto inserted, server side. Your case here is slightly different to the requests we’ve had already (e.g. auto inserting datestamps into mutations) but it sounds like an interesting case to consider.