Road to 1.0.0 - Policies and better loaders

[stefan-gorules]

Hi everyone 👋 ,

We've been working on a major milestone in the background and will be rolling out a version 1.0.0-beta within the following week. After a lot of experimentation and effort, we have landed on a new concept for managing the business logic called Policies. During the research process, we've gained a clearer understanding of what perfect editing experience looks like. Our focus over the next couple of months will be to deliver on that better experience through static analysis and catching mistakes before they happen in the runtime.

With the policies, this feature comes out of the box. Graphs will remain central to our experience and will receive a revamped experience that includes many great things we've learned while building policies (static types, refactoring, dependency tracking, etc.) without any breaking changes.

Policies - Documents with Rules

Policies are a new way of declaring the rules. The first and most noticeable difference compared to the graphs is how they are represented visually. Instead of creating the nodes and connecting the edges, you can write a document that contains both rules and documentation. The rules are automatically ordered and prepared for execution through backtracking layer by detecting dependencies of each rule block.

They also come with great tools:

• Statically knowable types of input and output schema
• Ability to do simple refactors (rename properties)
• Understanding the types and all dependencies of each rule
• Diagnostics to catch the errors before-hand
• Easy to reason about traces

Policy definition

Inspecting evaluation (answering "Why?")

Loaders - Simplifying Developer Experience

We're adding a couple of new options for the loaders to simplify usage of .zip releases and statically available rules. Particularly:

• Async function loader (existing and remains supported) - Slowest and allows for most control
• Static loaders (zip/fs/content) - Allow for pre-compilation and one-shot loading of whole project

For example, the API for NodeJS might look something like:

const engine = new ZenEngine({
  loader: {
    type: 'zip',
    bytes: await readFile('./bundle.zip')
  },
});

Forbidding unsafe in core

With the release of 1.0.0-beta we will also be hardening the core by removing any unsafe entries. Unsafe might still have its place inside of bindings where more control between different layers (e.g. napi-rs) is needed, but our goal is to try not to use unsafe within the core Rust packages in the future, unless a very specific reason arises.

---

What beta means in this case

We expect the beta line to run for a couple of months. We're want to ensure API contract stability rather than racing to 1.0.0. The features are expected the work on every beta release, but the API might get breaking changes between versions as we converge towards design goal.

The business logic will remain 100% reverse compatible and functional, although the API surface and wiring might change.