First, thanks for the work on SAPIENT and for the thoughtful design of the v2.0 version — it's been really useful to build on. I'd like to suggest a small, backward-compatible addition that would smooth out a few integration pain points.
Node hierarchy is currently expressed only top-down: Registration.dependent_nodes (field 8) lets a parent list its children, but a child's Registration has no field referencing its parent. The relationship is discoverable only from the parent side.
-
Main problem — partitioning by parent. Routing all of a parent's dependent nodes to the same consumer/partition (keyed by parent ID) requires the parent's registration to be seen first. The protocol gives no ordering guarantee that a parent registers before its children. A child registering first can't be routed and must be buffered or reprocessed — forcing stateful, globally-coordinated ingestion instead of stateless sharding on a self-contained key.
-
Authorisation. Where authorisation is scoped by parent station ID, dependent-node events can't be authorised on receipt: each event carries only its own node_id, so the parent must already be resolved to determine permissions. This creates the same ordering dependency and races on the security path — a child's events arrive un-attributable to a parent and can't be authorised (or get wrongly denied) until the parent registration is processed.
-
Domain mapping. Mapping the SAPIENT domain onto an internal model is hard without a back-reference: there's no way to tell from a node's own registration whether it's a standalone node or merely a "module" that can't exist on its own and requires a parent station. This distinction has to be inferred from some other parent's dependent_nodes, rather than declared by the node itself.
Also:
- No self-contained routing — consumers must hold full parent state to resolve any child.
- Fragile on reconnect/re-registration — no authoritative back-reference to rebuild the edge from the child side.
Proposed change (backward-compatible):
optional string parent_node = 11 [(field_options) = {is_uuid: true}]; // UUID of this node's parent node (if any)
First, thanks for the work on SAPIENT and for the thoughtful design of the v2.0 version — it's been really useful to build on. I'd like to suggest a small, backward-compatible addition that would smooth out a few integration pain points.
Node hierarchy is currently expressed only top-down: Registration.dependent_nodes (field 8) lets a parent list its children, but a child's Registration has no field referencing its parent. The relationship is discoverable only from the parent side.
Main problem — partitioning by parent. Routing all of a parent's dependent nodes to the same consumer/partition (keyed by parent ID) requires the parent's registration to be seen first. The protocol gives no ordering guarantee that a parent registers before its children. A child registering first can't be routed and must be buffered or reprocessed — forcing stateful, globally-coordinated ingestion instead of stateless sharding on a self-contained key.
Authorisation. Where authorisation is scoped by parent station ID, dependent-node events can't be authorised on receipt: each event carries only its own node_id, so the parent must already be resolved to determine permissions. This creates the same ordering dependency and races on the security path — a child's events arrive un-attributable to a parent and can't be authorised (or get wrongly denied) until the parent registration is processed.
Domain mapping. Mapping the SAPIENT domain onto an internal model is hard without a back-reference: there's no way to tell from a node's own registration whether it's a standalone node or merely a "module" that can't exist on its own and requires a parent station. This distinction has to be inferred from some other parent's dependent_nodes, rather than declared by the node itself.
Also:
Proposed change (backward-compatible):
optional string parent_node = 11 [(field_options) = {is_uuid: true}]; // UUID of this node's parent node (if any)