-
Notifications
You must be signed in to change notification settings - Fork 8
Blockchain microservice architecture
The blockchain microservice is split into a websocket server and a REST API server that provide all communication with a node. The implementation of the microservice should be opaque to the backend, it should merely need to communicate over the documented endpoints and websocket messages.
A websocket server provides real-time information on contributions. All business logic is separated by notifiers
which have their own namespace and set of messages for sending and receiving. All websocket messages are formatted redux style, like so:
{
"type": "namespace:type",
"payload": { /* anything */ }
}
The notifiers and their message types are as follows:
{
to: string; // The address it was sent to
amount: string; // The amount that was sent, in base unit
txid: string; // The transaction id for the send
memo: string; // The attached memo, can be empty string
contributionId: number; // The contribution id this maps to
}
An Express REST API is provided to allow for request-response interactions from the backend. Rather than piggy-back on the websocket server, the REST API is for when information sent to the microservice needs validation with the node, or requires a semi-immediate response. The API is authenticated using the same secret key as the websocket server in the Authorization
header. The endpoints are as follows:
Parameters:
-
contributionId
(number) - The numeric contribution ID from the backend. Must be numeric, since it will be used as address derivation index.
Response:
{
"data": {
"transparent": "tm5vA...",
"sprout": "ztJa4..."
}
}
Errors:
- 500 if there's a failure with node communication
Parameters:
-
disclosure
(string) - Hex disclosure fromz_getpaymentdisclosure
.
Response:
{
"data": {
"valid": true
}
}
Errors:
- 400 if the disclosure is missing / incorrect format
- 500 if there's a failure with node communication