When we were designing Convector, one of the fundamental goals we wanted to achieve was to make the blockchain interaction as smooth as possible for the developers.
Most of the languages and libraries available today for blockchain development use a lot of complicated terms, the mental model of a blockchain developer often gets obfuscated with the underlying blockchain technology, and as I've mentioned before, a blockchain developer should focus in the application logic rather than the technology running behind it.
Today it doesn't take a database expert to build a software consuming it. Tomorrow it won't take a blockchain expert to build a software using it.
- Walter Montes
A blockchain at its roots is a data store that most of the time is protected by a set of pre-defined rules, often called Smart Contracts or Chain Codes.
This is why in Convector we choose a familiar terminology for the core principles of the framework, one of the most successful patterns in the application development field: MVC (mode-view-controller), which basically consists on having a Model describing your data and a Controller taking actions over the model.
So let's say you want to create your own cryptocurrency. The properties of its model will be things like: name, symbol, total supply, balances, creator, etc. Its controller is conformed by methods like: transfer, approve, transfer from, mint, etc. If you're a tech savvy, you've already realized those are all concepts from the Ethereum Standard ERC-20.
Curious on how to create an ERC-20 token with convector? Take a look!
We could have stopped in here, we already had a pretty solid model on how to shape smart contracts easily. But when we were migrating the contracts of our internal applications, we realized that if we wanted to make blockchain development really easy we not only had to make the creation straight forward but also its consumption.
We found ourselves writing back-end and UI services duplicating the methods to invoke the smart contracts. This is bad :(
We came up with the idea to take the same controllers and models we already created for the smart contract layer and take them over to all the other layers, like the server or browser, so we could confidently execute a line like
Token.transfer(100, '0x165DE7FA3E5') no matter if we were on the browser, server, or blockchain context and it will be smart enough to take the necessary steps towards performing a blockchain transaction.
We needed a way to change the logic used to communicate with the blockchain based on the environment. In the browser there's no blockchain, all you do is invoke an HTTP method to either the blockchain API directly or an intermediate back-end endpoint that will invoke the blockchain for you.
Controllers needed an adapter to resolve the actions they perform to the models. In the browser this might trigger an HTTP call to the back-end. In the back-end this might trigger an HTTP call to the blockchain. In the blockchain itself it actually performs the steps to validate the transaction, i.e.: can the transaction author transfer these tokens?
Models needed a storage layer where they could perform CRUD operations. Again, in the browser this might be send a query transaction to the blockchain or send an HTTP request to the back-end. In the back-end this might be read from a generated database or query the blockchain. In the blockchain this might be search for the block's information.
The Controller-Adapter and Model-Storage pattern has allowed us to think even further:
Interoperability. In a near future you’ll regularly connect with multiple blockchains on the same application, same thing as you do right now with different APIs. Having the ability to talk to multiple blockchains within the same framework is something we're aiming to. Right now Convector officially supports Hyperledger Fabric, but this is just the first of the multiple blockchain platforms we want to support.
Beyond Smart Contracts. One of the most common escenarios of a blockchain application is to integrate with existing data sources like APIs and databases. Since the Adapter/Storage mechanism allow us to specify the communication protocol decoupled from the Controller/Model implementation, it makes it really easy to discriminate what actions of your logic do you want to route to the blockchain and what actions are handled on other systems.
About the author
CTO at WorldSibu & Software Architect, passionate about Blockchain, AI and technology in general. You can find me as @diestrin everywhere.