search

Capstone-DayScape / dayscape-backend

Repository for the backend of the DayScape project for the 2024 CSC 490 Senior Capstone
0 stars 0 forks source link

readme

DayScape backend

Backend application for DayScape (dev frontend deployment)

API Documentation

Development

This is a Python Flask application that provides an API to be used by dayscape-frontend.

The application is built automatically by Cloud Build and deployed under a static endpoint for each environment in Cloud Run. The Dockerfile describes the Cloud Build container, but you can directly run and edit the Python application for faster development.

Requirements:

Secrets Management

Secrets (such as API keys) are either stored in Secret Manager, or eliminated by authenticating with directly to a Google Cloud API using application credentials. On the Cloud Run deployments, the application is automatically authenticated using the dayscape-backend service ID. To run locally, you must create a credential for this service ID and save it on your system.

I recommend saving it in ./.adc.json, which is in .gitignore to prevent accidental publishing. (Note that if you DO accidentally commit this file, Google will detect it and disable that credential.)

Then export the following variable so the Google Cloud client libraries can use the key:

export GOOGLE_APPLICATION_CREDENTIALS=.adc.json

Configuration

Aside from the Google credentials ↑↑↑↑, all configuration is documented in config.py.

By default, the configuration assumes you are deploying to your workstation. This is true for the backend and frontend. You should not need to set any configuration in either repository (aside from the Google credentials) for the backend to automatically serve its API to the frontend, which is running at http://localhost:3000.

Using Python Venv

To install the Python package dependencies, you can use python -m pip install -r requirements.txt. However, it is recommended to use a virtual environment to install the packages.

You can add the following alias to your .bashrc, or just enter the commands locally in your shell when you want to work on this application:

vactivate () {
    python3.12 -m venv .venv
    source .venv/bin/activate
    python3.12 -m pip install -r requirements.txt
}

Windows:

vactivate () {
    python -m venv .venv
    source .venv/Scripts/activate
    python -m pip install -r requirements.txt
}

Run the application

python app.py

Or, to mimic exactly how we run multiple workers in the Cloud Run containers:

gunicorn --bind :5556 --workers 1 --threads 8 --timeout 0 app:APP

Then you can check that the API is working by vising http://0.0.0.0:5556/api/healthcheck

Tests

Install Pytest:

python -m pip install pytest

Run tests:

python -m pytest

For more info, this is a good introduction to testing in Python.

E2E Tests

By default, the E2E tests will run against the static dev endpoint in Google Cloud. You can optionally set the backend url (if you are running against your local deployment or another deployment somewhere):

export BACKEND_URL=http://localhost:5556                # or http://0.0.0.0:5556 if you are testing the container

Run test:

python -m pytest tests/e2e.py

Container Development and Deployment

The development steps above describe how to build and run the Python application on bare metal on your workstation. In reality the application is deployed as a container to Cloud Run. Each push to a branch will build and deploy to the dev instance, and when you merge a PR with master, the same will happen for prod.

Building and Running the Container locally

In order to build and test the container, you need the docker or podman command installed on your system. These instructions use podman, but they should be interchangeable.