Web content management system (CMS) allows non-technical users to make changes to an existing website with little or no training. CMS is a Web-site maintenance tool for non-technical administrators.
A few specific CMS features:
A few well-known Raku/Perl6-based content management systems and frameworks:
General benefits of blockchain data storage:
Why CMS is well decentralized application:
Proof-of-Authority (PoA) does not depend on nodes solving arbitrarily difficult mathematical problems (like Proof-of-Work, PoW),but instead uses a set of «authorities» - nodes that are explicitly allowed to create new blocks and secure the blockchain. The chain has to be signed off by the majority of authorities, in which case it becomes a part of the permanent record. This makes it easier to maintain a private chain and keep the block issuers accountable.
Parity supports a Proof-of-Authority consensus engine to be used with Ethereum Virtual Machine (EVM) based chains.
A contract in the sense of Solidity is a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain.
To implement four basic functions of persistent storage (create, read, update and delete) we should implement the next methods in our contract:
Why Pheix? Why not!
We use external module Router::Right for URL routing. Router::Right is Raku-based, framework-agnostic URL routing engine for web applications.
This module was ported from Perl5 implementation:
Module repo: https://gitlab.com/pheix/router-right-perl6
Router::Right is well-documented, you could find docs, examples and best-practices in wiki: https://gitlab.com/pheix/router-right-perl6/wikis/home
Net::Ethereum module is a Raku interface for interacting with the Ethereum blockchain and ecosystem via JSON RPC API.
Module is available from: https://gitlab.com/pheix/net-ethereum-perl6
This module was ported from Perl5 Net::Ethereum with some changes, but original documentation is still actual, so feel free to use p5 docs with Raku Net::Ethereum: https://metacpan.org/pod/Net::Ethereum
You should install Ethereum client (Geth, Parity, etc..) and Solidity compiler (optional) before using Net::Ethereum. You can work without Solidity with precompiled smart contracts.
When you're working with Ethereum blockchain you should permanently think about cost of your transactions (TXs). TX cost is estimated in gas.
TX cost depends on smart contract implementation: storage operations and dynamic arrays are expensive. Also TX cost depends on data amount to store on blockchain.
In private networks (PoA) you have unlimited gas amount, so cost of transaction is not a critical value. But amount of data is the thing, you should still think about. Big data decreases TX speed and utilize disk space, so it's a good idea to compress data before commit — text data can be compressed by LZW.
Pheix uses LZW::Revolunet module for LZW compression.
Common approach to increase speed of dApp is to minimize a number of TXs. First technique is to put caching tools to top data-storing layer and increase reading speed. Syncing with blockchain should be done after cache expiration. Cache expiration period should be the configurable value.
Most known Raku caching modules are:
It's usual practice to avoid TXs mining wait in dApp. You have got TX hash immediately after TX sending, so you should analyze it asynchronously. By default Parity Ethereum PoA node mines new block every 15 seconds, that's why syncing with mining results is terrible, slowpoke technique.
Pheix provides the next solution: we've got TX hash, and immediately return a page with JS asynchronous Ajax code (callback). This code will raise pop-up notify message with TX results ASAP.
This solution requires the back-end functionality, that provides checking TX status by hash from front-end.
Lazy loading is an efficient pattern to save resources and increase response time while reading data from blockchain. In Pheix we store text data in 4KB frames (e.g. 100KB text is stored in 25 frames), so when we need to output the text preview, we do not read whole text — we're reading just first frame. Also we show <MORE> hyperlinks with async JS callbacks everywhere it's not conflicting with UI/UX.
Frames are useful while store data on blockchain. When we post 100KB text — we proceed pipeline of 25 4KB frames with async technique, discussed on previous slide. Pipeline provides ability to output progress bar or equal widget, that show process status.
Pheix has database independent API layer with basic data access methods (CRUD). So, it's possible to connect any regular relational database, supported by Raku DBIsh module: https://github.com/perl6/DBIish. Hybrid model of data storing supposes that you optimize your dApp in the next directions:
Regular relational databases are good for no-critical data: if it will be tamper, nothing critical happens.
Flat-file database is similar to relational database in terms of data integrity and tamper protection. Ok, relational DBs have built-in user accounts, permissions, etc... But in sense of data tamper they are vulnerable.
Flat-files are efficient quick-start solution on low-resources devices or servers with restricted install permissions. Flat-files databases could be syncing with popular clouds out-of-the-box and have advantages such as: simple dumping, cross server moving and backuping.
Flat-file database is simple to load to blockchain with trivial JS parsers.
Pheix uses blockchain as a database (ledger) that is shared across a private PoA network. This ledger is encrypted such that only authorized parties can access the data. Since the data is shared, the records cannot be tampered. Thus, the data will not be held by a single entity.
By decentralizing data storage, we improve the security of the data. Any attack or outage at a single point will not have a devastating effect because other nodes in other locations will continue to function.
Blockchain is good for tamper-proof data: vote results, ratings, test marks, bug tracks, changes history and others.