google / cel-spec

Common Expression Language -- specification and binary representation
https://cel.dev
Apache License 2.0
2.59k stars 216 forks source link

Function Definitions and Variables #313

Closed stopachka closed 9 months ago

stopachka commented 9 months ago

Hey team, I know CEL was inspired by work with firestore rules. In firestore though, I notice it's possible to define ~functions.

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

From what I understood, these are not quite as powerful as real-world functions (they don't allow for recursion, and can only have one return. But, it is nevertheless quite handy.

I'm curious, is there a plan to support something like this in CEL?

TristonianJones commented 9 months ago

@stopachka good question.

We don't plan to introduce variables or functions into CEL; however, products on top of CEL are able to do so as long as they keep the following things in mind:

  1. Syntax is impossible to turn off (or should be considered this way), so a dedicated syntax for functions adds dedicated complexity and maintenance.
  2. Tools which are design to catch complexity statically will often be wrong in some subtle way. These tools are as much of a help as they are a liability.
  3. Functions (and variables to a lesser degree) can be a denial of service attack vector. Are you able to limit the scope of the impact of a bad expression, or trust the expression authors?
  4. If you introduce functions and variables, why not use a larger, better supported language like TypeScript, etc.?

Assuming you feel comfortable with these statements and questions, and Firestore did because they added a lot of production safety controls on top of the language, then it's perfectly reasonable to introduce something like this in your own product; however, CEL can't introduce such functionality for all products because some products that use CEL are in very latency critical paths (more than 100M evaluations/s).

stopachka commented 9 months ago

Understood, thanks for the detailed response @TristonianJones!

re: 4: mainly because it would be hard to sandbox and keep fast. Our use case is similar to firestore rules. Will look deeper into ideas!