Galv backend (REST API)

A metadata secretary for battery science

Check out the demo

API client libraries:

The Galv backend provides a REST API powered by Django and Django REST Framework.

Galv Project

• Backend
• Frontend
• Harvester

For more complete documentation, see the Galv Server documentation.

Demo instance

There is a public demo instance of Galv (reset every week) available at galv-demo.fly.dev.

Deploying

The Galv backend is deployed using Docker. You can deploy the Galv backend in a number of ways.

Docker image

Each release is accompanied by a Docker image. The latest stable version is tagged as latest. You can acquire the image by pulling it from GitHub Packages:

docker pull ghcr.io/galv-team/galv-backend:latest

You can then run the image using the following command:

docker run -p 8001:80 ghcr.io/galv-team/galv-backend:latest

You will need to add in a database and set the environment variables appropriately. You will also need to add environment variables as detailed below.

Docker Compose

Galv can be deployed using the Dockerfile provided in this repository. Example usage is provided in the docker-compose.yml file. This is generally for development, however, so you will need to add a database and set the environment variables appropriately.

Envvars

You should ensure that all environment variables in the .env file are set correctly before deploying. These variables can be set by editing and including the .env file, by setting them in the environment, or by setting them via a hosting platform's interface.

Development

Development is most easily done by using the provided Dockerfile and docker-compose.yml files. The docker-compose.yml file will start a postgres database and the Django server. The Django server will automatically reload when changes are made to the code. The following command will start the server:

docker-compose up app

The server will be available at http://localhost:8001.

Gotchas

• The docker-compose file only mounts the galv-backend directory, so if you add a new file or directory, to the project root, you will need to rebuild the container.
• The app container is started with server.sh. If this file has acquired non-LF line endings, the container will report that it can't be found when starting.

Setting up in PyCharm

To set up the development environment in PyCharm, make sure there's a project interpreter set up for the Docker container. Once you have that, create a Django server configuration with the following settings:

• Host: 0.0.0.0 (this allows you to reach the server from your host machine)
• Port: 80 (not 8001 - this is the port on the Docker container, not the host machine)

Documentation

Documentation is generated using Sphinx. To make it easy to develop documentation, a Dockerfile is provided that will build the documentation and serve it using a webserver. It should refresh automatically when changes are made to the documentation.

The docs container is started with docker-compose up docs. By default, it will serve at http://localhost:8005.

Versioning

The documentation supports multiple versions. To add a new version, add a new entry to docs/tags.json. These tags must be in the format v*.*.* and must be available as a git tag. Tags that match v\d+\.\d+\.\d+ will be tagged as latest when released. Tags with a suffix, e.g. v1.0.0-beta, will not be tagged as latest.

There is a fairly complex workflow that will update the documentation for all versions when a new version is released. This workflow is defined in .github/workflows/docs.yml, with help from docs/build_docs.py.

Testing

Tests are most easily run using the provided Dockerfile and docker-compose.yml files. The docker-compose.yml file will start a postgres database and run the tests. The following command will run the tests:

docker-compose run --rm app_test

Publishing

Versioning

We use Semantic Versioning. When you make a change, you should update the API_VERSION in galv_backend/config/settings_base.py.

If you update the documentation, you should also update the release version in docs/source/conf.py and add the new version tag to docs/tags.json.

These versions should all use clean SemVer versioning, i.e. v*.*.*, where the *s represent the major, minor, and patch versions respectively.

Published versions should be released incrementally.

Compatibility checks

New versions of the API should be compatible with the previous version. If this is not the case, you should increment the major version number.

The CI workflow will check for compatibility issues in the OpenAPI spec by comparing the current version of the spec with the first version of the current major version.

Compatibility checking is done for both the OpenAPI specification and the database schema. The OpenAPI spec is checked using the check_spec container, which runs the openapi-diff tool. The database schema is checked using Django's built-in migration system during staging deployments (versions ending with -rc#).

Tagged releases

When you want to release a new version, using the GitHub Actions workflow, create a new tag. The tag should be a SemVer version, optionally with a qualifier (e.g. v1.2.3-alpha).

Make sure the tag's version matches the API_VERSION in galv_backend/config/settings_base.py.

E.g. if your API_VERSION is 1.2.3 you can create tags like v1.2.3, v1.2.3-alpha, v1.2.3-rc1, etc.

Release candidates

Tags that end with -rc# will be treated as release candidates.

When you create a release candidate, the GitHub Actions will deploy the candidate version to the staging server.

This deployment will run the migrations, etc. so we can detect if something is likely to break in production.

Demo version

The demo instance is published every week, and with every release.

GitHub Actions

We use a fairly complicated GitHub Actions flow to ensure we don't publish breaking changes. The configure-workflows.yml action is run on every push to the repository, and it determines which workflows to run based on the branch/tag and the contents of the repository.

When you push to a branch, the following actions are considered:

• Configure workflows
• Run tests (A)
• Build and publish documentation (B)
• Build and publish OpenAPI spec (C)
• Build and publish API client libraries (C)
• Build and publish Docker images (A)
• Issue a GitHub release (A)
• Deploy staging instance (D)
• Deploy demo instance (E)

The triggers are: A. changes in backend_django, or other code files like requirements.txt or Dockerfile B. changes in docs C. B & changes to the OpenAPI spec (i.e. the specifications are not equivalent) D. tags that match v*.*.*-rc# E. if the tag is the latest release version

N.B. Changes are calculated vs the previous release, not the previous commit.

Requirements:

The configure-workflows.yml action also checks a couple of requirements:

• The version in the tag must match the API_VERSION in galv_backend/config/settings_base.py.
• If the tag is a release (v*..), there must not be an existing release for the same version.
• If there are breaking changes in the OpenAPI spec, the tag must be a major version.

To run the OpenAPI compatibility checks locally, run the following command:

docker-compose run --rm check_spec

You can optionally specify the REMOTE_SPEC_SOURCE environment variable to check against a different version of the galv-spec.

cp my_spec.json .dev/spec
# .dev/spec is mounted as a volume at /spec in the container
docker-compose run --rm -e REMOTE_SPEC_SOURCE=/spec/my_spec.json check_spec

Releasing with AWS

We use AWS (Amazon Web Services) to host a few instances. There is a repository that contains the AWS Cloud Development Kit (CDK) code to deploy the Galv backend to AWS. The workflows for the staging and demo instances use this CDK code to deploy the Galv backend to AWS.

To perform a manual deployment to AWS, please follow the instructions in the CDK repository.