Blockchain: Thinking BIG for Users.
#Blockchain #IPFS #GraphQL
Building blockchain applications is hard. A steep learning curve, churning standards and lack of documentation are just a few of the challenges we have faced. However, with a lot of time, effort and perseverance we’ve been able to build blockchain apps that a person with a solid understanding of wallets, cryptocurrency and blockchain can actually use. And that’s great.
But why not build apps that anybody can use? After all, there will be no widespread adoption of any app unless anybody can use it, right? The reason?Because building usable blockchain apps is really, really hard. In our quest for the holy grail of usability, we have learned a few things about our users.
- Most users will not install plugins to use our app.
- Most users will not buy cryptocurrency to use our app.
- Most users will not tolerate slowness in our app.
- Most users will not learn about blockchain to use our app.
Yes, its true. We had to accept that most people will not use our app if they have to install a wallet, purchase crypto, or patiently wait for 2000 NFTs to download from the blockchain. They will not learn about Transactions, Events, and Public key cryptography to use our app. They just won’t.
How, we asked ourselves, can we possibly build a fully decentralized blockchain app that is usable by everybody? The conclusion we came to is this:
We can’t. At least not yet. And that’s OK.
In order to tell you how we came to this conclusion but more importantly what we did about it, let me describe our journey.
The metamorphosis of a dApp.
When we first built our dApp it looked something like this.
It was a single-page app using Web3/MetaMask to connect to the blockchain and an IPFS API to connect to IPFS. It was simple and elegant. It worked, and we were happy.
But not really.
Our app was slow. The hundreds of roundtrip requests to the blockchain and IPFS took time.
Then, as our requirements became more complicated we realized that we needed a place to store our mutable data. This mutable data did not belong on the blockchain and it did not belong in IPFS. Where to put it?
Legacy technology to the rescue!
We configured a Node.js server and connected it to a PostgreSQL database to store our mutable data. We created a REST API and used Axios on the client to communicate with it.
After these changes our new architecture looked like this:
We now had a single-page app using Web3/MetaMask to connect to the blockchain with the addition of Node.js server PostgreSQL to handle mutable data. It worked, and we were happy.
But not really.
By adding Node.js and PostgreSQL we had sacrificed the purity of our dApp. To our disappointment, we realized we could no longer legitimately call our blockchain app a dApp (Decentralized App) at all. Being the decentralization maximalists we were, this took some getting used to.
And our app was still slow.
Then, our requirements became even more complex. We realized that some of our blockchain transactions needed be signed and sent from the server and not from the client. In order to achieve this feat we added an in-memory Hierarchical Deterministic Wallet to our server and tweaked the code to sign and send transactions to the blockchain.
Our new architecture looked like this:
Now we had a single-page app using Connex/Comet to connect to the blockchain (note: during this iteration we switched from Ethereum to VeChain, but that is another story). We still had a REST API to handle mutable data. But now, in addition to the client, we had the server reading and writing to the blockchain.
We now had a hybrid centralized/decentralized blockchain app that derived few of the advantages of decentralization and suffered from the usability issues that plague decentralized apps.
Things had gotten out of hand.
So, how did we get here?
At the beginning we had a simple, elegant, dApp. Sure, it was a little slow and sure, to use it, the user the had to install a plugin, buy cryptocurrency and understand blockchain. But that was OK because we were deriving all of the benefits of decentralization including (but not limited to):
- Attack resistance
- Fault tolerance
- Collusion resistance
- Data immutability
But as our requirements became more sophisticated our app had become more centralized. Consequently it no longer benefitted from all the advantages of decentralization. While our app still had Collusion Resistance and Data Immutability (the important data still being on the blockchain), our move towards centralization had sacrificed certain levels of Fault Tolerance and Attack Resistance. We now had to rely more on traditional strategies to handle security and architectural redundancy.
And anybody who wanted to use our app still had to install a plugin, purchase cryptocurrency and understand blockchain.
It was time to rethink our goals.
BIG Thinking: Re-evaluating our goals
As an exercise, we decided to stop thinking of centralization as the enemy.
Was it possible to create a blockchain app that harnessed the traditional power and simplicity of centralization while still using the parts of decentralization that really mattered to our customers?
With this new philosophy in mind, we set out to completely redesign our architecture with usability as our primary focus. This is what we came up with.
After a few weeks of development, we now had a serious, full blown client-server architecture with built-in caching written on a rich and highly-supported Java platform:
Suddenly our app became easier to use. It also became more robust and easier to develop. Segmentation of concerns meant that development could occur in a more modular fashion and bugs were easier to find and fix.
Here are the benefits we derived from embracing centralization.
- Increased usability. Users do not have to install plugins or buy cryptocurrency. Anybody with a phone or a browser can use our application. (The are some exceptions for more advanced features).
- Increased speed. All client/server communication goes through our GraphQL API. This means blockchain, IPFS and SQL data is merge and cached on the server. This results in much faster reads.
- Users do not have to understand blockchain. As far as the user is concerned, blockchain is just the hidden magic that works to protect their resources.
But, it doesn’t end there. Our new choice of architecture had hidden advantages that we hadn’t anticipated.
- Faster development. The rate to iterate and to prototype is much faster with GraphQL than with REST.
- Even faster development. The GraphQL-SPQR API allows us to rapidly develop GraphQL. No need to maintain a schema.
- Our customers now have access to a full-blown Developer API.
- Easier hiring. We don’t have to find front-end developers who already understand blockchain. We only have to find developers who are good at front-end development and understand GraphQL.
The Birth of BIG
After we had built our new system we raised our periscope to discover that we are not the only ones who have taken this journey. Unbeknownst to us, the people at The Graph had already built an ambitious and decentralized Blockchain, IPFS and GraphQL ecosystem for reading Events from the Ethereum blockchain. By building your own subGraph you can provide developers with a scalable GraphQL API for your dApp. We love what they are doing and can see that it is going to be BIG.
How does The Graph differ from our framework?
- Our framework is specific to our vertical (Blockchain Serialization). TheGraph is a full-blown ecosystem.
- Our framework is specifically for VeChain (so far). TheGraph is for Ethereum (so far).
- Our framework both reads and writes to the blockchain. AFAIK TheGraph is read-only.
It took a lot of experimentation, work, and perseverance to get where we are, but the addition of GraphQL to our existing Blockchain and IPFS framework allowed us to crack the code on user experience. Of course there are some trade-offs (there usually are) but we are happy to say that we have created a blockchain framework that is scalable and that anybody can use. Its going to be a BIG year for crypto.