docker volume create --name redis_bounties docker volume create --name psql_bounties docker-compose up
Locally, you will now be syncing directly from the contract. You may access the api at:
The API will automatically restart if you make code changes. To turn off the services, run
docker-compose down. Keep in mind, the volumes make it so your DB and redis cache will be in the same state if you start the services again with
docker-compose up. If you would like to wipe out your databases and start again, then run:
docker-compose down docker volume rm redis_bounties docker volume rm psql_bounties docker volume create --name redis_bounties docker volume create --name psql_bounties docker-compose up
If you add additional packages to a package.json or to the requirements.txt file, you'll need to rebuild the individual service. To rebuild all services, you may run:
docker-compose down docker-compose build docker-compose up
By default, the sync will connect to mainNet. To change to a rinkeby sync or other, you will need to adjust the eth_network key in the environment file. As an example, it can be changed to
API Schema and Documentation
The frontend or client can be any third party service or collaborator that integrates with the standard bounties ethereum contract. This API works as a caching and storage layer for what is input into the standard bounties contract. Due to storage costs, the contract puts the majority of the data into IPFS. To understand further, read the documentation on the standard bounties contract.
The contract subscriber listens for events from the contract. In the case a resync is occurring, it will listen to all historical events, starting from the genesis block. In order for the subscriber to know what it has already accessed, the redis cache stores a currentBlock key. Additionally, the redis cache stores the hashes for all transactions that have already been evaluated and stored to the db. The contract subscriber will ignore transactions that have already been written, and will not search through blocks prior to the currentBlock key. When the subscriber picks up on a new event, it looks up the original transaction via web3 and passes the event data along with the original contract function inputs to SQS. An SQS fifo queue is used. This means we will never have duplication on keys and all events will be handled in the order they come through.
The bounties subscriber listens to events that have been passed into SQS by the contract subscriber. The bounties subscriber uses the data from the event, the inputs to the original contract function, and the IPFS stored data to write the appropriate values to the DB via django.
The bounties api is a django API that serves the data that has been written by the bounties subscriber and other running jobs.
Other Jobs include: