EPR Registration Tool

Links

• Repo: GitLab
• Designs: Figma
• Test Server
  • Django Admin: api.epr-test.ambient.digital/admin
  • GraphiQL: api.epr-test.ambient.digital/graphql
  • Wagtail: api.epr-test.ambient.digital/cms
  • Frontend: epr-test.ambient.digital
• Local
  • Django Admin: localhost:8000/admin
  • GraphiQL: localhost:8000/graphql
  • Wagtail: localhost:8000/cms
  • Frontend: localhost:3000
  • Storybook: localhost:9009
  • Mailhog: localhost:8025

Project Structure

• Backend /backend/README.md
• CMS /backend/README.md
• Frontend /frontend/README.md
• e2e Tests /e2e/README.md
• ADRs /docs/decistions/

Quick Start

1. Follow "Local development" instructions in backend README
   • run backend
   • create/load data
   • setup first wagtail page
2. Follow "Run project" instructions in frontend README

Deployment

In order to run this application, you need to start three separate components:

• A postgres database (postgres version 14), where we recommend to provide a managed database
• The backend application, which is written in Django
• The frontend application, which is written in Next.JS and hence also runs server-side

Kubernetes

We strongly recommend deploying this application in a Kubernetes environment, because this makes it easy to scale the different parts of the application depending on the load and to ensure availability through redundancy.

You can use the provided helm charts to install the application. In this setup we assume a managed Postgres database is provided and linked through the values set under the "db" section of the values file.

IMPORTANT NOTE: Using Kubernetes environment only for hosting single small application can introduce significant maintenance overhead for that reason this option is not recommended in case there is no existing Kubernetes setup in the first place.

Other setups

You can also install this application in other docker-based setups such as AWS ECS or standard servers. However, in case of using standard servers necessary solutions should be put in place to meet necessary scalability and availability requirements.

To install on a root server, you can manually start a docker container for the frontend and backend as well as the database. Alternatively you can use docker-compose in a similar way as the provided docker-compose setup that we use for local development.

To install this application without using docker, you can use the provided dependency management tools (Pypi in the backend and npm in the frontend).

Hardware requirements

Test Environment

Minimum required resources in order to host test environment is as follows;

• 2 vCPU & 4 GB Memory Note that we recommend running two instance of frontend and two instance of backend application in the test system for high avialability purposes. Resources in the test system can be divided evenly between backend & frontend application.

We do use a hosted postgres database service (version 14 or higher) with 2 CPU & 4 GB memory instance. We suggest that database is hosted on a seperate instance then where the test application is running. We suggest having minimum of 7 days of backup for test environment for database.

Production Environment

Minimum required resources in order to host production environment is as follows;

• 4 vCPU & 8 GB Memory Note that we recommend running two instance of frontend and two instance of backend application in the production system for high avialability purposes. Resources in the production system can be divided evenly between backend & frontend application.

We do use a hosted postgres database service (version 14 or higher) with 2 CPU & 4 GB memory instance. We suggest that database is hosted on a seperate instance then where the production application is running. We suggest having minimum of 30 days of backup for production environment for database.

IMPORTANT NOTE: Please note that, resources required to run production environment may need to be increased over time according to the actual usage from the users.

Helm Charts

When making changes in the Helm Charts, follow these steps

1. increase version in Chart.yaml
2. adjust TEST_HELM_CHART_VERSION in CI/CD pipelines
3. push + merge your code
4. create a new tag in GitLab from the target branch called helm-x.x.x (adjust version).

Now the new helm-chart version is available for deployments.

pre-push hooks

Git pre push hooks for Backend and Frontend are in .pre-commit-config to activate it run in the project root dir.

pre-commit install --hook-type pre-push

You may need to install pre-commit if not already installed

pip install pre-commit
brew install pre-commit     (mac alternative)

Glossary

EPR

extended producer responsibility
(erweiterte Herstellerverantwortung)

Packaging Report

A representation of single data report for packaging material, created by a company.
One packaging report can hold up to two submissions, one for the forecast and one for the final data.
We called it "Packaging" Report, to separate it from reporting tools of the application.

Submission

One set of material records, defining the quantities per material and material group for one period of time.
A submission either represents the forecast data OR the final data ("actual quantities""

Maintenance

Backend

 # We use Tilde ~ with fixed major and minor version "~=X.Y", this will look for compatible versions on update.  
 pipenv update

Frontend

# List all outdated packages (major, minor, patch).
yarn outdated
# only upgrade to patch and minor releases
yarn upgrade

License scanning

We took out license scanning jobs from a check scanning result job (check trivy scan results) as we want this to show only the security check issues results. Check trivy scan results: filters out the operations system license issues and show only installed packages issues, so to see the license scanning results, check pls the job logs itself, and ignore the first table (OS Packages (license)).

• epr-trivy.yaml: Lists all unknown licenses to ignore them in the check result, and the license which we are fine with.
• .trivyignore: File to list all the ignored security issues (we don't have one)

Notes:

• GPL license: Such packages are most likely fine if used in the backend because we don't distribute the package to the users, but might require you to disclose the sourcecode to every user if used in the frontend. Check with the Privacy Circle if in doubt.

For more pls check gitlab-trivy-license-checks

Push Mirror from Gitlab to Github

The project repository is mirrored from Gitlab to Github using push mirroring mechanism provided in Gitlab. More info about push mirroring here.

Shortly after a push to Gitlab repository, the Github repository of the project should be updated. If this does not happen automatically, please check if fine-grained Github access token is expired. Please contact Ambient ops to create a new token.

A push mirror can also be forced by Gitlab maintainers of the project. Select Settings > Repository. Expand Mirroring repositories. Press Update now.