Hyperledger Fabric: Kick-starting my career as a software developer.

Published in

wearetheledger

11 min readMay 12, 2018

Halfway through March I started my internship at TheLedger. An IT-consultancy company specialized in blockchain technology. I got the assignment to emulate a supply chain network with Hyperledger Fabric. I learned so much in such little time, especially compared to school. This experience reminded me how much fun learning can be when it’s something you’re really interested in and when you can put that knowledge to good use. This article will span the couple of weeks that I’ve spent at TheLedger so far and to me these weeks have been eventful and very interesting.

Now at the start the assignment was pretty vague. I knew there was a sensor board involved, which was going to act as a physical front end to my implementation. The technology that I was told to use was Hyperledger Fabric.

Hyperledger Fabric?

Hyperledger Fabric is an open source implementation of blockchain technology, intended as a foundation for developing blockchain applications or solutions. Hyperledger Fabric allows components, such as consensus and membership services, to be plug-and-play.

Like other blockchain technologies it has a ledger, uses smart contracts and is a system by which participants manage their transactions.

Hyperledger Fabric is different than other blockchain solutions though. Other systems are permissionless, in other words unknown identities can participate in the network (through Proof of Work protocols for example) to be able to validate transactions. Hyperledger Fabric can use different types consensus algorithms that are not bound by cryptocurrencies, because of the private nature of the network. By default, Hyperledger Fabric uses Practical Byzantine Fault Tolerance (PBFT) as consensus algorithm. And you can create channels, so that only the peers that need the information that gets uploaded get to see them. On these channels you can upload chaincode: the smart contracts of Hyperledger Fabric. For more information about Hyperledger Fabric I’ll point you towards their documentation.

Where to even start?

With no or little prior experience with JavaScript and Golang I had no clear idea of where to start. That’s when you turn to your colleagues to point you in the right direction. I got tons of information that I could consume for a while before I got to meet the client who made the sensor board.

After plowing through the documentation for a while I felt like I was ready to try to set up a small project. A colleague of mine had a small course on writing and using chaincode for Hyperledger Fabric in Golang which helped me out immensely to make changes to the existing code and to understand what I was doing.

My first meeting, exciting!

The client brought the board with him. He brings it to conventions to showcase and demo what possibilities they have and what they can do for other companies. It was very impressive, he made it from the ground up. A bunch of sensors everywhere, like light sensors or heat sensors, which triggered something else like a fan that started spinning. All of these sensors were set up to look like three factories. And the whole board was made to emulate a supply chain case. Supply chain? Ideal use-case for a Hyperledger Fabric implementation! They wanted to hook up this board to a blockchain network. Hence their partnership with TheLedger. They threw some quick ideas out there, for example all the fans turning emit CO2. Every company has a maximum they are allowed to emit. So this data for emission gets pushed onto the blockchain. They gave me freedom to start tinkering with this information. Basically they wanted us to make an API so that they can push information onto the blockchain.

Here is a video that showcases this board:

TheLedger gave me the opportunity to handle this case mostly myself. I could communicate with the client if I had any questions or wanted to keep them up to date. Which felt like a big responsibility for someone who isn’t used to being in the business world yet and I’m very grateful for this opportunity.

Back to coding!

While it was fun to play around with Golang for a while it was time to move on to Hyperledger 1.1. Most notably this update brought chaincode support for NodeJS. Which makes a big difference for someone like me who is trying to learn. The downside with working with this version is that the alpha released in January this year. This means that hardly any documentation is to be found anywhere and the scarce documentation that does exist isn’t always amazing.

Luckily my colleagues had recently made a boilerplate that I could use. Which simplified things for me immensely once again. Using this NodeJS boilerplate I made my own little project that had a couple of small features like adding factories and handling their emission levels.

The only way to push transactions in this project was through the CLI. Something like:

peer chaincode query -n mycc -c '{"Args":["queryFactories","a"]}' -C myc

So the logical next step was to provide an API that the client could communicate with. Being new to JavaScript I played around with an express server for a while at first. Express is a minimal and flexible javascript framework to quickly and easily create an API. Once I got a bit familiar with express I incorporated query code that came with the ‘first-network’ from Hyperledger itself.

Now with every good API comes documentation, so swagger was a good option for this. Swagger is the largest and most well known framework, which has a lot of developer tools for creating, designing, documenting, testing and deploying API’s.

So I took a while to research how to use swagger properly with express. I created a new project with the swagger CLI tool. This basically does a lot of the express server setup for you. The only thing you have to do is edit the swagger.yaml file. This is basically a file that gives you the familiar swagger look to your endpoints. Here’s a small example of such a swagger.yaml:

OAI/OpenAPI-Specification

OpenAPI-Specification - The OpenAPI Specification Repository

github.com

You can define all the endpoints you want to showcase here with all of its possible models and responses. The other thing you have to do is actually write your endpoints, now you get a basic example of this in the base project of swagger CLI. You can connect these to your swagger.yaml by exporting the functions with the function names equaling the operationId in the swagger file.

Now I did this in a very messy way. For example I made new files for every query I wanted to execute. Doing a lot peer configuration every time I queried something. But I’ll get back to that later.

Sensor board? Sensor suitcase!

It was time for a second meeting to discuss the next steps of our project. The client had a lot of new amazing ideas for our collaboration. He wanted to rework the entire idea of the board, the board was fairly large and a hassle to carry around, so he thought of the idea to make the board into a suitcase instead.

The suitcase would be easier to transport, but that was not the only change he had in mind. He reworked the idea of the factory emission system. Basically the new suitcase would involve three new scenarios. The first one was pretty familiar, the left side of the suitcase would have four compartments, every compartment representing one factory. These factories will each have a way to start running with different kind of sensors. This would visually be represented by a fan for example. And again this data will be committed to the blockchain.

But once the emission exceeds a maximum, a sort of invoice will be created so that it can be tracked which factory (or company) exceeded their limit. After which a small printer would be able to print out this information. But since the suitcase is a tool for pitching ideas quickly to a lot people the pitches will be very small. For this reason a reset button is a good idea. Once you’re finished with one pitch the next could be set up by just pressing one button. This would reset the blockchain to its base state while keeping the history (in essence the emitted emission will be reset to 0 and the invoices will be ‘archived’).

The second scenario would be on the right side of the suitcase. It would zoom in on one of the factories and showcase a machine. This machine will also have a couple of different ways to interact with, again with different sensors. This time what will be tracked is individual factors in this machine like temperature or humidity. If these factors exceed or go below the allowed limit another invoice will be created so these can be printed out as well.

And lastly he will hook up a module that can receive GPS signals, so he can track where the suitcase has been so far.

All the data involving this case will be posted on the blockchain.

Time to refactor

With these new fresh ideas I got excited to go and implement these. But like I said earlier my code was far from clean. It was around this time TheLedger participated in the 2018 Blockchaingers Hackathon. It was the largest physical blockchain hackathon in the world. And TheLedger won! Read more on this event from the perspective of our developers here. Congrats to the participants once again!

Now why is this important to my story? They decided to use Hyperledger Fabric and they gave me access to their code. In other words I finally saw an implementation of how a proper Hyperledger Fabric project is set up. I threw out the code I didn’t need and started implementing the scenarios the client asked of me the proper way. Thanks to my previous experiences with the technology and the amazing guidelines laid out by my colleagues, I had very little issues at this point to create the new endpoints.

The AWS learning curve

(AWS stands for amazon web services, it’s a platform which provides a bunch of different services like online service deployment, etc. Read more on AWS here)

AWS was convenient here so that the client could access my API just wherever he was on whichever device by just going to the link.

Now this is the part that would have taken me literally weeks, but thanks to my colleagues it only took days to get my project up and running online. I’m not very accustomed to docker, dockerfiles and docker swarm. Hyperledger Fabric consists out of docker containers that communicate with each other and the swagger project also needed to be dockerised if it wanted to communicate properly with the network. My colleagues have done something similar to my project already so they helped me out a lot to get the scripts right, so that with every git push to the master branch would also be pushed to AWS.

Te(k)st adventure

At some point it got mentioned that I should take a look at testing. Since it’s very important to ensure the quality of any software application. I started with familiarizing myself with JavaScript testing and several testing frameworks, I was baffled that concepts like stubbing and mocking wasn’t more prevalent in one of our courses (especially since we had an entire course on testing). It took a while before I understood the difference between these and their importance.

Since the project was written in TypeScript I started looking for TypeScript testing frameworks. The other developers of TheLedger mostly use Mocha so I started looking in that direction. Sinon is most commonly used for mocking and stubbing in JavaScript, but I ran into some problems using Sinon with TypeScript. A lot of callback functions were used in the examples of Sinons documentation and I also had some issues because of the strongly typed nature of TypeScript. So I decided to look into some other frameworks that were a bit more TypeScript specific.

I stumbled on this article that explained the differences between two TypeScript mocking frameworks, ts-mockito and typemoq.

TL;DR Typemoq has a lot of advanced features and ts-mockito has very self-explanatory syntax. After some testing with both frameworks myself I found that they were both pleasant to work with… Until I ran into some issues here as well. Basically calling then() on stubbed or mocked functions that return a promise resulted in errors. The funny thing is that usually if one framework threw that error the other framework would work fine. It also seemed very arbitrary which functions worked and which didn’t. This an awful way to work in my opinion so I reverted to looking for better Sinon solutions. Which I did find after a while.

First actual demo

At this point I’ve implemented all my ideas for all the scenarios that our client had in mind. We start going over the different scenarios, he explains what goes on physically on the suitcase, so a bunch of different sensors and again with spinning fans. He didn’t expect that a lot of the calculations were already done on our part. For example for the zoomed in machine scenario: the only thing he has to do is update the values of the machine, the API calculates all the time related values and creates the invoices automatically based on the time difference between Date.now() and the last time update was called. A question I got immediately after explaining this was how long it would take to change the minimum and maximum allowed values for the machine properties in the code, for which I had already written an API endpoint to do just that.

Overall he seemed to be quite impressed, he told us that the way we designed the API makes his work a lot easier. He just has to think about his own architecture and the different variables he would like to use. I can’t wait to see the final product. Together we created a pretty cool demo to introduce people to the idea of blockchain in a supply chain scenario. The next steps on my side are just a bit of fine tuning and then we should be done.

Conclusion

So far I’m really glad I ended up where I did, I learned a lot in the couple of weeks I’ve been here in terms of technology but also the general work flow. I loved working here so far and a big reason for that is that I’m surrounded by a lot of smart and warm people.

As my co-intern mentioned in his article though the impostor syndrome is very common among new developers and I am no exception. I feel like I’m not good enough or I’m never doing enough. I want to improve at a faster rate than I’m currently doing. Even though those expectations are probably way over my head, so maybe I shouldn’t stress too much about it.

Either way, I’m excited as to see what my future in this industry holds.

Next on the list is taking a look at Hyperledger Sawtooth which is also a good technology to store supply chain related data. I will probably make another blog post soon to showcase the progress on the suitcase and for my findings on sawtooth.