Anthem by Chorus One

Welcome to the Anthem codebase!

Anthem is a multi-network platform for managing Proof-of-Stake participation and data for blockchains like Oasis, Celo, Cosmos, Terra, Kava, and others. Anthem is open source and built and maintained by Chorus One.

Try out Anthem now at: https://anthem.chorus.one

👩‍🚀 Getting Started

You will need NodeJS and yarn installed to proceed.

# Clone the repo
$ git clone https://github.com/ChorusOne/anthem.git

# Use Node LTS (alias default if you want)
$ nvm install 12.18.0 && nvm alias default 12.18.0

# Install Lerna
$ npm i -g lerna

# Install dependencies
$ lerna bootstrap

# Build the utils/ package
$ yarn utils:build

# Setup environment variables
$ yarn setup

# Start the server
$ yarn server:start

# Start the client
$ yarn client:start

# Start the client app in development mode (no server required)
$ yarn dev

We recommend using VS Code and installing the recommended workspace extensions to make development easier.

For the application to work fully locally, you will need to obtain specific environment configuration variables. If you need to do this, please contact a Chorus One team member.

🗃️ Overview

The codebase is organized into a monorepo with the following packages:

• client/: React client application.
• cypress/: Cypress e2e test suite.
• server/: GraphQL/Express API server.
• utils/: Shared utils, tools, and types.

NOTE: Each package contains a README document with more specific information about that package.

The utils/ package includes shared code which the other packages import. If any updates are made to this package, it will need to be rebuilt. If updates are being made frequently, the package can be built in watch made using yarn utils:watch. Note that sometimes your text editor may not immediately detect changes to the utils/ build output, when the build changes.

🚧 Testing

The entire project is written in TypeScript and all packages follow the same testing conventions. You can run tests at the top level or in any package with the following commands:

# Run Prettier
$ yarn prettier

# Run TSLint
$ yarn tslint

# Run the TypeScript compiler
$ yarn tsc

# Run all the above tests
$ yarn test

You can also run yarn prettier:fix or yarn tslint:fix to use the auto-fix options for these tools to fix any issues (or yarn format to run both in one command). Normally, any linting/styling issues should be fixed automatically on-save if you are using VS Code with the recommended extensions.

The above commands cover static and unit testing the codebase. Additionally, we maintain a suite of e2e tests written with Cypress which you can run with the following commands:

# Start the client application (it needs to be running for the tests)
$ yarn dev

# Run the Cypress tests
$ yarn cypress

This will run the Cypress tests. You can see the Cypress package README for more information.

🛰️ GraphQL

The project relies on GraphQL for the majority of the APIs. The GraphQL schema exists in the server package. To work with GraphQL, some tooling exists to generate TypeScript type definitions from the GraphQL schema. This generated code is in the utils/ package and can be imported and used by other packages. to generate the type definitions, run the following:

# Generate TypeScript type definitions for GraphQL schema
$ yarn types

🏗️ Development

Some additional tooling exists to record mock API response data to use for offline development and to run the app for the Cypress tests. The mock data is generated by running the server, querying all of the GraphQL endpoints and recording the responses. If any GraphQL APIs are updated or changed, this mock data needs to be updated. To update this data, run the following commands:

# Regenerate types
$ yarn types

# Start the server in recording mode
$ yarn recording

# Run the script to record the data
$ yarn record

Note that if you update the client data you may have to update the client test snapshots, since some of the tests use this mock data. In addition, if you add a new union type to the GraphQL schema, you will need to add union type resolvers. And if this response type is used in the mock development mode, you will need to add a union type resolver in the client/ codebase as well (see the graphql/mocks.ts file).

The development can be run with the command:

# Run development mode
$ yarn dev

This runs the client app and uses the stored mock response data, which allows the client dashboard to be run without a server running. This also supports mocking the Ledger integration for testing.

📜 Internationalization

Some notes on the internationalization scheme can be found here.

📦 Docker Images

The docker image for the Anthem backend server can be found on Docker Hub. The latest release is kept up to date with the master branch of this repository.

A docker image for the frontend application will be available shortly.

📟 Kubernetes

A Kubernetes manifest file for the backend server is included in packages/server/anthem.yaml.dist

🚚 CI/CD

Docker is used to build and test the project for CI/CD. You can find a Dockerfile and docker-compose file in the root directory, and other specific Dockerfiles as need in the individual project packages. The commands used to build these are:

# Install dependencies and build the application
$ yarn docker:build

# Run all tests (static, unit, and cypress tests)
$ yarn docker:cypress

The repo uses GitHub Actions to run CI/CD test and deployment pipelines. These pipelines are configured in the github/workflows directory. The client application is currently deployed using Netlify and the backend is deployed on Chorus infrastructure.

📝 Contributing Guidelines

We use the Gitflow Workflow for developing new features. This involves pulling the master branch, developing your fix or feature on a new branch, and then creating a pull request for your code changes. It is recommended to try to keep pull requests simple and confined to a concise set of changes to make it easy to review and merge code. Pull requests require review and all status checks (continuous integration checks, for instance) to pass before merging is allowed.

Any bug fixes, improvements, or new features are welcome. Pull requests must be reviewed and pass all project tests. If you are interested in contributing, feel free to explore the open issues or open an issue if you have an idea for an improvement or new feature.