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:

1. Presentation and administration layers;
2. Web page generation via templates;
3. Scalability and expandability via modules;
4. WYSIWYG editing tools;
5. Workflow management (access levels, roles).

A few well-known Raku/Perl6-based content management systems and frameworks:

1. Uzu — static site generator with built-in web server, file modification watcher, live reload, themes, multi-page support;
2. Cantilever — CMS for Raku with built-in web server and flat-file database;
3. November — A wiki engine written in Raku, the oldest from known P6 content management systems;
4. Cro — a set of libraries for building reactive Raku-driven distributed systems, Cro is the most promising framework for web applications now;
5. Bailador — light-weight route-based web application framework for Raku with integrated web-server.

General benefits of blockchain data storage:

• Improved data privacy and security: data in a blockchain network is highly secure and tamper-evident;
• Increases data reliability and speed: data in the blockchain is broken down and stored in the nodes within the network;
• Cost reduction in cloud computing;
• High availability and accuracy of data;
• Storage is decentralized.

Features:

• Tracking all changes for any dataset stored in the blockchain: e.g. if you have record with user Foo details, you get full changes history out-of-box;
• Account management: decentralized application is distributed over nodes (private network) and every node has built-in account: you could use this to restrict access in your app (create binding node→functionality).

Restrictions:

• You should use the blockchain with embedded smart contracts only (Ethereum, Hyperledger, TON);
• It is preferred to store text data.

Why CMS is well decentralized application:

• Presentation and administration layers should be deployed on independent nodes: presentation on public server, administration on private workstation;
• Administration layer (content workflow) is presented by access-restricted nodes: user from nodeA has create permissions, user from nodeB has edit permissions, user from nodeC has publish permissions;
• Users from administrative nodes have roles, ensured by private transactions; e.g. different users from nodeA with create permissions could have additional roles: creating articles, news, announces.

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:

• new_table(string tabname);
• drop_table(string tabname);
• set(string memory tabname, uint rowid, string memory rowdata);
• insert(string memory tabname, string memory rowdata, uint id);
• select(string memory tabname, uint rowid);
• remove(string memory tabname, uint rowid).

Pheix strengths:

• Object-oriented architecture;
• Light weight and scalable;
• Modules with basic functionality for complex projects;
• Search engine optimization features;
• Extension components development with open API;
• Fast cycle from install to start up;
• Multi-language support;
• Out-of-the-box integration with Ethereum blockchain and Redis.

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:
https://github.com/mla/router-right

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

Pheix is dependable on:

• JSON::Fast:ver<0.9.12>
• HTTP::UserAgent:ver<1.1.49>:authgithub:sergot
• Net::Ethereum:ver<0.0.95>
• Router::Right:ver<0.0.44>
• LZW::Revolunet:ver<0.1.2>
• OpenSSL:ver<0.1.23>:authgithub:sergot
• MIME::Base64:ver<1.2.1>:authgithub:retupmoca
• Template::Mustache:ver<1.0.1>:authgithub:softmoth
• MagickWand:ver<0.1.0>:authgithub:azawawi
• LibraryCheck:ver<0.0.9>:authgithub:jonathanstowe:api<1.0>
• GeoIP2:ver<1.1.0>

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:

• Cache::Memcached — Raku client for memcached a distributed caching daemon, https://github.com/cosimo/perl6-cache-memcached;
• Redis — Raku client for Redis server, https://github.com/cofyc/perl6-redis;
• Propius — Raku memory cache with loader and eviction by time, https://github.com/atroxaper/p6-Propius.

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:

• classify your data — tamper-proof data, tamper-sensitive data, temporary data, cache, etc...;
• store different types of data in different storages.

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.