You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This implements the routing of API requests to specific
Cactus nodes based on a pre-specified ledger ID.
The idea is that since each Cactus node has it's own API host
we can store the ledger connector + ledger associations in the
consortium definition and use that to look up which nodes can
we send requests to when wanting to transact on a specific ledger.
The theme here is to offload the bulk of the routing to consortium
management.
This is the first half of the routing solution that will also
have to include a back-end component that will ensure that
requests end up at the right connector plugin instance if the
same plugin package is used within the same Cactus node but for
connecting two separate ledgers which are of the same type, e.g:
Two Fabric 1.4.x ledgers with their own ledger connector instances,
both running in the same Cactus node (e.g. `ApiServer` class instance).
Side effect: The cactus-sdk package now has to depend on the
cactus-plugin-consortium-manual package which is the simplest
(and only at the time of this writing)
consortium management implementation we have on hand and is therefore
a natural/prime candidate for being the default consortium definition
provider to power the client side component of the routing.
The majority of the routing functionality is implemented within the
`ApiClient` class of the SDK package and for now it only supports
routing based on specific ledgers, but not other pluggable aspects.
To avoid circular dependencies because of the above, the plugin packages can
no longer depend on the sdk package which is also reflected in this change.
Other side effect: Reusability of OpenAPI spec types is now partially in effect
by way of having the core-api package export it's own types into a fixed,
version controlled .json file which we'll be able to reference online as well
through direct links to the github repo files (which helps because OpenAPI
uses JSON references to resolve dependent specification schemas)
Signed-off-by: Peter Somogyvari <[email protected]>
0 commit comments