From 613c3f32dd35b516f214f60b3cd6676ac6a5f865 Mon Sep 17 00:00:00 2001 From: AnthonyAmanse Date: Sun, 29 Apr 2018 23:19:43 -0700 Subject: [PATCH] Add initial architecture and flow Signed-off-by: AnthonyAmanse --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 29a1a2f..b868bf1 100644 --- a/README.md +++ b/README.md @@ -5,9 +5,9 @@ 1. The REST API is how the mobile app will interact with the blockchain network. The API will acknowledge the request and the mobile app will receive a unique key (random numbers and letters) which will be used to get the blockchain’s response later. 2. The API just stores the request in a queue in RabbitMQ. The queue has 2 channels, which are for the user (Fitcoin org) and the seller (Shop org). The requests can either be: - * User enrollment - * Query data from the blockchain network (number of kubecoins of a user, products that are for sale, contracts, etc…) - * Invoke or perform a transaction (send steps to receive kubecoins, claim a product, complete a transaction, etc…) + * User enrollment + * Query data from the blockchain network (number of kubecoins of a user, products that are for sale, contracts, etc…) + * Invoke or perform a transaction (send steps to receive kubecoins, claim a product, complete a transaction, etc…) 3. The execution workers use the Hyperledger Fabric Node.js SDK to perform above requests. They are listening to the requests from RabbitMQ. 4. The workers send the requests to the Blockchain network and are then processed. The blockchain network uses NFS to persist the ledger and state database. 5. The workers receive the response and then persists it in the redis database with the unique key from (# 1).