In the previous lesson, we covered how to connect to and query the Hyperledger node. Now, we’ll explore how the node can be configured to respond to those requests.
In this example, the file Fabcar.js contains our chaincode SDK. This file gives us a single convenient place to add and remove functionality. Let’s take a look at a couple of the function calls to see how they work.
As you can see, all that’s really happening here is a quick query that pulls cars 0 - 999 by their IDs. The SDK is taking care of the heavy lifting and abstracting all of this away so that we can just play through the iterator object, which is just an extension of the state object that we have at our node. In this way, a highly secure blockchain IDE can be used with comparable ease to a standard database.
You can try running different commands using the query function, but we’ll go through a few of them now.
The Invoke Process is a bit more complicated than a standard db write since there is a consensus process taking place behind the scenes. Rather than writing directly, the application must submit ‘update transactions’ to the chain, which are then ordered (think ‘mined’) into the ledger after being approved by the other nodes. As a result, we’ll be using invoke.js ( fabric-samples/fabcar/invoke.js ) to write to the Hyperledger database while query.js can be used to read from it.
To see how this is happening, you’ll want to take a look under the hood and check into how invoke.js differs from query.js. The main difference is the addition of the addOrderer call shown on line 5 below. As you can see, the user’s hfc key is imported from the local directory and used as the Fabric_Client’s default.
In the following example, we’ll use the payload in lines 61-68 to try creating and modifying some entries in the system!
