Usage by language
Which runtime to use where, the versions each one supports, and the calls every runtime has in common.
Every runtime implements the same specification and passes the same conformance suite. Pick the one that runs where the decision is made.
| Runtime | Use it in | Page |
|---|---|---|
| TypeScript | Browsers, Node.js, React, React Native, Electron | TypeScript |
| Java | Spring Boot and any JVM | Java |
| Go | Go services | Go |
| Python | Services, jobs and tooling; the reference implementation | Python |
| Command, WebAssembly module | Any other language, CI scripts, sandboxes | Command and WebAssembly |
| Rule server | Callers that should not run an engine, over HTTP | Rule server |
Supported versions
The minimums are declared by each package. CI tests the versions in the last column on every push. No maximum is declared: newer versions are expected to work, but only the tested ones are proven.
| Runtime | Declared minimum | Where it is declared | Tested in CI |
|---|---|---|---|
| TypeScript, rule server | Node.js 20 | engines in packages/typescript/package.json and packages/server/package.json | Node.js 20 (Linux), 22 (Linux, Windows, macOS) |
| Java | Java 17 | maven.compiler.release in packages/java/pom.xml | JDK 17 and 21 (Linux), 21 (Windows, macOS) |
| Go | Go 1.22 | go directive in packages/go/go.mod | Go 1.24 (Linux, Windows, macOS) |
| Python | Python 3.10 | requires-python in packages/python/pyproject.toml | Python 3.10 (Linux), 3.12 (Linux, Windows, macOS) |
| WebAssembly module | A WASI preview 1 host | GOOS=wasip1 build | Node.js 22 and wasmtime (Python) |
The same calls everywhere
| Step | TypeScript | Java | Go | Python |
|---|---|---|---|---|
| Read a compiled bundle | RuleSet.fromBundle(json) | RuleSet.fromBundle(map) | rulecascade.FromBundle(json) | RuleSet.from_bundle(json) |
| Compile a source ruleset | loadRuleSet(document, registry, options) | RuleSet.load(document, registry, schemaLoader) | rulecascade.Load(document, registry, loader) | load(document, registry, loader) |
| Evaluate | rules.evaluate(request, channel?, operators?) | rules.evaluate(EvaluationRequest) | rules.Evaluate(request, channel, operators) | rules.evaluate(request, channel="server", operators=None) |
| Load error | LoadError (.problems, .codes) | LoadException (problems(), codes()) | *rulecascade.LoadError (.Problems) | LoadError (.problems, .codes) |
| Malformed request | RequestError | IllegalArgumentException | *rulecascade.RequestError | ValueError (RequestError) |
| Operators a manifest needs | missingOperators(manifest, operators) | rules.requiredOperators(Channel.SERVER) | operators of rules.Manifest("server") | rules.manifest("server")["operators"] |
Two kinds of failure are deliberately different:
- A load error means the ruleset or bundle must not be served. Let it stop the process at start-up.
- A rule that cannot be evaluated never throws. It produces a blocking finding with code
RULE-EVALUATION-ERRORand the decisiondeny. See Incident: RULE-EVALUATION-ERROR spike.
Installing from the repository
The packages are not published to a registry yet. Every page installs from a checkout:
git clone https://github.com/YarlisAISolutions/rule-cascade.gitPin the checkout to a commit or tag in your build, the same way you would pin a registry version.
Incident: RULE-EVALUATION-ERROR spike
Blocking RULE-EVALUATION-ERROR findings are rising. Find the rule and the cause from the finding's detail, reproduce offline, and fix the host or roll back the bundle.
TypeScript and JavaScript
@yarlisaisolutions/rule-cascade: evaluate in the browser, in Node.js and in React; compile rulesets in Node.js.