Skip to content

Commit

Permalink
Detail ADR0003
Browse files Browse the repository at this point in the history
  • Loading branch information
ch1bo committed Jun 9, 2021
1 parent 665d1f4 commit 79b8a87
Showing 1 changed file with 16 additions and 4 deletions.
20 changes: 16 additions & 4 deletions docs/adr/0003-asynchronous-duplex-api.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,13 +8,25 @@ Accepted

## Context

The [_reactive_ nature of the Hydra node](0001-record-architecture-decisions) means _Request-response_ paradigm is not a good fit to provide a _Client API_: Clients input a _stream_ of _commands_ to a node which in turns issues a stream of _responses_ representing the observable outcome of previous commands and interaction with peers in the network.
The [_reactive_ nature of the Hydra node](0002-reactive-core.md) means that
clients produce a _stream_ of _inputs_ to a node which in turns issues a stream
of _outputs_ representing the outcome of previous inputs or resulting from
interaction with peers in the network.

For example, a client may send a _command_ as _input_, upon which the node might
do something. When that something is finished, a _output_ does indicate that.
However, there might also be an _output_ emitted to the client when another peer
interacted with "our" node.

Queries, messages by clients which do only fetch information from the node, are
not in scope of this ADR.

## Decision

* The main API is exposed using the [Websocket](https://datatracker.ietf.org/doc/html/rfc6455) protocol with inputs and outputs conforming to some textual representation of `Command`s and `Result`s.
* We use a single, full-duplex communication channel per client connected to a Hydra node
* This is implemented using a simple [Websocket](https://datatracker.ietf.org/doc/html/rfc6455) with messages corresponding to `Input`s and `Output`s.

## Consequences

* Client software should be implemented accordingly and most notably cannot rely on any kind of synchronous response to give feedback to potential users or higher-level clients.
* Clients can receive "responses" decorrelated from any requests, for example as the consequence of actions carried out by other nodes
* Clients needing a synchronous API need to implement it on top
* Clients can receive _outputs_ decorrelated from any _inputs_ and at any time

0 comments on commit 79b8a87

Please sign in to comment.