Streaming Plugins

[ch1bo]

Why

SundaeLabs has submitted a Catalyst Proposal to extend the hydra-node APIs by "streaming plugins".

As also described int he proposal, there is a need for a customizable and flexible mechanism to log, analyze, and react to the event and transaction flow in a Hydra node. While the existing websocket-based API could be used for some cases, it does not fit all requirements when integrating a Hydra node into a production system.

The goal of the proposal and this matching feature is to take a first step into the direction of configurable streaming API(s) and extension points.

What

• The hydra-node must use by default the same existing file-based, JSON encoded persistence mechanism = non-breaking change
• Refactor the hydra-node to provide designated extension points to how events are consumed and where the same events are sourced from
• No runtime configuration of which plugins / extensions to use
• Selecting a different set of plugins / extensions requires recompilation of the hydra-node
• Extension points are documented as such and tests ensure no accidental breaking changes on the interfaces

How

• Design and document the solution as an ADR, Streaming adr #1157
• EventSource and EventSink abstractions for Hydra Extensibility #1351
• Write a "How to extend the hydra-node"
  • Including an example event source / sink
  • How to test and enable it (by recompiling)

[ch1bo]

@Quantumplation @cardenaso11 Created this item to capture SundaeLab's work on this.

[ch1bo]

@cardenaso11 can you please contribute the UDP or another example to complete this besides merging #1351 ?

[ffakenz]

Example on "How to extend the hydra-node"

extend-hydra-node-sinks.md

Applied at fork: https://github.com/ffakenz/hydra/tree/udp-sink

[ffakenz]

closed by #1413