badger/api
2023-05-08 15:39:47 -05:00
..
abis feat: no more onchain archived 2023-03-24 23:33:30 -05:00
api feat: functional discovery + org retrieveal 2023-03-24 00:15:15 -05:00
badge feat: url encoded art links 2023-03-26 16:47:29 -05:00
balance fix: unique_together bug 2023-03-16 14:27:38 -05:00
indexer feat: get symbol from uri 2023-03-26 17:00:50 -05:00
ipfs feat: api authentication deprecation 2023-03-16 15:54:57 -05:00
module feat: add config...() to loader 2023-03-17 11:50:56 -05:00
organization feat: chain icon display and address copy 2023-05-08 15:39:47 -05:00
utils feat: user creation ens integration 2023-03-17 17:34:34 -05:00
wallet Merge branch 'feat-badger-day' into feat/resolve-all-ens 2023-03-17 17:38:25 -05:00
.gitignore fix: same process background indexer 2023-03-09 23:15:34 -06:00
abis.py fix: abis 2023-03-13 17:38:49 -05:00
Dockerfile.dev fix: indexer adjustments 2023-03-09 18:23:11 -06:00
manage.py Base contract 2022-07-06 16:52:00 -05:00
Procfile feat: deploy Procfile 2022-10-14 14:49:30 -05:00
README.md fix: indexer docs 2023-03-04 15:42:24 -06:00
requirements.txt fix: deprecate use django-apscheduler 2023-03-10 20:07:21 -06:00
runtime.txt fix: granular runtime 2022-10-14 14:53:46 -05:00

Badger API

The interface backend of Badger is driven by Django, Redis and Postgres. The database is prepared to support simple HTTP requests and WebSockets.

The Indexer Checking The Chain

There are many types of EVM listeners available, each with their own purpose. Badger includes 2 key types of listeners:

  • backfill - A one-time listener that will backfill the database with all events of a given type.
  • listen_for - A listener that will listen for new events of a given type.

A backfill is used to populate/seed the database with all events of a given type. For Badger, in the local configuration this is not required as the node will always start at block 0. In a production environment, backfill should be ran on a regular basis to ensure that even when blocks are missed, the database will be up to date.

Given a long horizon, a backfill can take a long time to complete. To mitigate this, the backfill command is designed to be run in parallel. The backfill command will spawn a number of processes equal to the number of cores on the machine. Each process will listen for events of a given type and write them to the database. The backfill command will not exit until all processes have completed.

The listen_for command is designed to be run in a long-running process. It will listen for new events of a given type and write them to the database. The listen_for command will not exit until the process is killed and if it crashes, it will be restarted by Docker.

By default, everything is configured for you in the docker-compose.yml file.

When using management commands, the available types are:

  • organization
  • badge

in place of the <type>

docker-compose run --rm badger_server python manage.py backfill_<type>
docker-compose run --rm badger_server python manage.py listen_for_<type>