This repository serves as a general guide and proof of concept for deploying a full-stack web application onto blockchain-based decentralized infrastructure.
The repository is structured as a monorepo - with infrastructure configuration, application frontend code, and application backend code all in one repository. This is done so that anyone can clone or fork this one repository and begin to experiment with deploying a decentralized web application.
The demo application deployed in this guide is a note app - with create, read, delete functionality. It serves as a minimal proof of concept for deploying a multi-tier web application to decentralized infrastructure.
The application code, technology choices, and configuration used in this repository should provide a general enough base to fork and adapt, or just reference, for future decentralized web application development.
A deployed live demo was deployed using the steps in this guide. Link below:
Deployment of the front-end to Skynet is handled automatically in this repository, using GitHub Actions. When any update to the application/frontend/ directory is pushed to the master branch, the Action workflow will be run automatically by GitHub. This workflow tests, builds, and deploys the static files to Skynet.
The result of this GitHub Action is a Skynet registry entry that provides a constant point of reference for your DNS record. The Skylink itself changes with each deployment to Skynet and would require you to constantly update your DNS record if referencing it directly.
Step 5 - Configure Handshake domain
Once your GitHub action completes, in the Action log in GitHub under the Deploy to Skynet step, you will see a link to https://siasky.net/skynet/registry with parameters in the URL for publickey and datakey.
You now need to copy those param values and create your skyns:// URL in the format skyns:///. The registry link will remain constant in the future, so this is a one-time manual step.
If using Namebase, you can now configure your Handshake domain to point to your Skynet hosted frontend by adding a TXT record under the Blockchain DNS Records section on your domain manage page. The value of this record is the skyns:/// URL that you just generated above.
This initial DNS configuration can take up to ~6 hours to be synced. For all future code changes pushed to the master branch, the Deploy to Skynet Action will automatically update your Skynet Registry data and you should see the changes reflected very quickly.
Although you can now make requests directly to your Akash URL over HTTP successfully, if you attempt to make these requests from your frontend that is being served over HTTPS, your API call will be blocked due to Mixed Content.
It is likely possible to enabled an HTTPS connection just using Akash deployment configuration but I was unable to find any documentation on this functionality.
The approach used in this guide is to sign up a free Cloudflare account and set up their flexible SSL/TLS encryption mode on a secondary (non-Handshake) domain in order to provide an HTTPS entrypoint that proxies requests to the Akash API server.
Support for HTTPS with Akash is something that I expect to explore further.
Step 7 - Setup Database Redundancy
Backend Redundant Postgresql infrastructure
The backend runs on Akash. Take a moment to review the Akash config. The backend stores the database on Akash. Currently, Akash does not have a persistent storage solution. This solution provides the capability to perform regular backups and database restoration via Skynet. This reference architecture provides the following capability:
Provide a redundant Postgresql configuration. pg-0 is replicated to pg-1
pg-0 - the postgres master starts up. When it first starts up, it will download an encrypted db backup from Skynet.
pg-0 - decrypts the backup and loads into the database.
pg-1 - the postgres standby starts up. and syncs with pg-0.
pgpool container starts up and connects to both pg-0 and pg-1 and automatically determines which one is master.
web container starts up and connects the the db cluster via pgpool.
If pg-1 or pg-0 goes down, pgpool will automatically re-route to the one that is active.
If the entire cluster goes down, the cluster can be re-deployed to Akash. It will then start up from the last backup.
The postgres Docker image will execute any .sh, load and .sql, .sql.gz file in /docker-entrypoint-initdb.d
Note that when testing this locally with Docker there are no volumes. This is by design. Everything persistent should be uploaded to the Skynet.
The pg-0 image initially loads pg-0/dbout.sh before the PG cluster is started. It reads in the following env vars: BACKUP_SYKNET_URL and BACKUP_PASS. The encrypted zip file is retrieved from Skynet and decrypts it with BACKUP_PASS. Finally, the DB backup is loaded into the PG cluster.
BACKUP_SKYNET_URL is used to retrieve the latest backup.
Based off the Bitnami pgpool project, this approach sets up three containers. pg-0 as a postgresql master, pg-1 as a postgresql secondary ( running as a hot standby), and pg-pool will determine which postgres container to connect to.
Testing Postgresql cluster in a test environment
# run the backend
$docker-compose up -d
# run the front end
$ cd application/frontend/ && npm install && npm start
# Connect to the browser at http://localhost:3000
Shut down pg-0 container
$ docker-compose stop pg-0
## verify that things are working as planned
# Connect to the browser at http://localhost:3000
# Should see all data still there. Try adding values
Step 8 - Setup database backups
Backup your data locally
To retrieve a live encrypted backup of the data, you can run the following command against the API:
# For testing locally with docker-compose
curl -v http://localhost/getsnapshot > dbout.zip
# For testing against AKASH deployment
# Obtain $AkashHost and $AkashPort from akash deployment (Consult Akash [documentation](https://docs.akash.network/guides/deploy) on how to obtain this)
Make sure to update the $BACKUP_PASS env variable in docker-compose.yml, akash/deploy-sample.yml. You will use the password to decrypt the zip file. You can use $BACKUP_PASS env var in akash/deploy-sample.yml to decrypt and examine the backup.
Upload local backup to Skynet
Upload the backup to Skynet with skynet-cli and store URL as BACKUP_SKYNET_URL
$ npm install -g skynet-cli
## send it to Skynet!
$ skynet-cli dbout.zip
## Take special note of the URL. This value will be used as **BACKUP_SKYNET_URL**
Look into the SkyNet registry for a simpler way to provide backup / restoration. Right now, each provision to Akash requires updating a new SkyLink URL. Using a Skylink Registry will allow the container to use a consistent skyns URL to retrieve the latest backup for ease of use.
Run demo application locally
To run the application locally, you can follow the steps below.
Stand up FastAPI and PostgreSQL backend
docker-compose up --build
In a separate terminal, stand up the React frontend
npm run start
You can now visithttp://localhost:3000 in the browser to access the UI. For testing the API, requests can be made to port 80, Example: GET http://localhost:80/api/v1/notes