Event Stream

The Event Stream represents all changes in the platform. The Event Stream is immutable, barring exceptional cases¹. In a more practical sense, the Event Stream is an append log of changes that run in the system.

Events are always posted against an Item reference, which represents the context for the event. Events also have a payload of properties.

External Events initiate all changes in Alpyne. They may be User Action, Time-Triggered², or an external system.

Internal Events are children of External Events. Internal Events are created as the result of Handlers.

Handlers

There are a number of Handlers that are invoked in response to events. Each handler “handles” a specific event. These are described later in the specification; as an overview:

• Mutations can read, write, and query data and generate other events. To put it another way; mutations are the means of changing data.

• Event Listeners respond to events. Like Mutations they can read, write, and query data and generate other events. There may be multiple listeners for a single event type.

Handlers MUST execute as a Unit-of-Work³. This includes all data changes and posting of events.

Queries are a form of Handler that does not interact with the Event Stream. Queries are read-only and do not modify data or generate events.

Side-Effects and Subscribers

Extensions to the Platform.

Circular References

Handlers can trigger other events, which may then execute other Event Listeners. That gives rise to the possibility of circular references; effectively a configuration that generates an infinite loop of events.

An event cannot invoke another event of the same event type (via Event Listeners). This is either directly, or via a chain of child events.

1. In the platform addChildEvent is used to create a list of events that may be generated as the result of an event. The Builder prevents any circular reference.

2. The Runtime MUST also prevent circular references and infinite loops.

Depth Limitations

Even precluding circular references, it is still possible to have a long chain of events.

The Runtime MUST impose a limit on the length of any event chain. This limit MUST be a minimum of 10. No specific maximum is specified.

Footnotes

1. Conceptually the event stream is always immutable, but there are exceptional cases such as accommodating GDPR “Right to Erasure” requests. ↩

2. Such as a “cron” scheduling event. ↩

3. In practice this equates to a single Database Transaction that spans all changes. ↩