You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have discussed this feature request with the community.
Describe the background of your feature request
As of today heimdall makes use of CEL for if conditions as well as for verification purposes of authorization conditions or results from corresponding endpoints. Even CEL is very fast, it is a separate language, which requires custom type bindings and it does not natively allow verification of functions in expressions. Latter is required to enforce the use of particular checks, like verification of used signature algorithms.
Describe your idea
Expr looks very promising. It has similar syntax as CEL but unlike CEL is compiled to go byte code. So, it is expected to be much faster then CEL. It does not require type-bindings as it is actually native go, which means less code and it allows definition of operator overloads, which is not possible with CEL in addition to the DSL like notation options. In addition, it allows verification of used expressions and code injection into those to provide secure defaults. That all makes expr very promising, maybe even as a drop-in replacement for CEL expressions.
Beyond that, it looks like expr could even be used as a replacement for go templates.
The actual task here would be to perform some research to gain knowledge required for taking an educated decision on how to proceed with the known CEL limitations as well as go templates verbosity.
The text was updated successfully, but these errors were encountered:
dadrus
changed the title
Consider applicability of [Expr](https://github.com/expr-lang/expr)
Consider applicability of https://github.com/expr-lang/expr
Dec 4, 2023
Preflight checklist
Describe the background of your feature request
As of today heimdall makes use of CEL for
if
conditions as well as for verification purposes of authorization conditions or results from corresponding endpoints. Even CEL is very fast, it is a separate language, which requires custom type bindings and it does not natively allow verification of functions in expressions. Latter is required to enforce the use of particular checks, like verification of used signature algorithms.Describe your idea
Expr looks very promising. It has similar syntax as CEL but unlike CEL is compiled to go byte code. So, it is expected to be much faster then CEL. It does not require type-bindings as it is actually native go, which means less code and it allows definition of operator overloads, which is not possible with CEL in addition to the DSL like notation options. In addition, it allows verification of used expressions and code injection into those to provide secure defaults. That all makes expr very promising, maybe even as a drop-in replacement for CEL expressions.
Beyond that, it looks like expr could even be used as a replacement for go templates.
The actual task here would be to perform some research to gain knowledge required for taking an educated decision on how to proceed with the known CEL limitations as well as go templates verbosity.
The text was updated successfully, but these errors were encountered: