Skip to content

Post and display messages online, using FastAPI, AWS Lambda, DynamoDB, Django, Google Cloud Run, Docker

License

Notifications You must be signed in to change notification settings

e-mit/fastapi-aws-django-gcp

Repository files navigation

FastAPI-AWS-Django-GCP

tests coverage flake8 mypy pycodestyle pydocstyle pylint pyright bandit aws-deploy docker-release-build release-test docker-hub-push gcp-artifact-push google-cloud-deploy

A demo project for posting and displaying text messages online, comprising:

  • A FastAPI app hosted on AWS, using API Gateway, Lambda and DynamoDB.
  • A Django app hosted on GCP, using Cloud Run, SQLite, Gunicorn and Docker.

View the FastAPI Swagger UI on AWS.

Try the Django app on GCP. (Note: please allow time for the slow GCR cold start).

Continuous automated test, build and deploy

Tests, linting and Docker build run via GitHub actions after each git push.

If all action workflows pass, the new Docker image (Django app) is automatically pushed to Docker Hub and deployed to Google Cloud Run as a new revision. The Cloudformation stack (FastAPI) is also created/updated on AWS.

Configure, build and deploy manually

  1. Run setup.sh to create the AWS stack, start the API and print the public endpoint URL
  2. Repeat these steps to update the stack if anything is changed. Changes can be applied more quickly by running stack.sh directly, in the following cases:
    • Update the lambda code
    • Update the lambda layer, which contains the Python dependency packages
    • Change the log level
  3. Build, check and push the Docker image

Local tests

These use uvicorn and the official test dynamoDB Docker container to run entirely without AWS cloud.

  • Unit and integration tests: ./run_tests.sh
  • Manual testing and evaluation: ./run_dev.sh

Cloud tests

After deploying to AWS, do ./run_cloud_tests.sh

Use notes

  • Google Cloud Run instances are started in response to user access, so will have an initial startup delay.
  • Cloud Run instances stay idle for up to 15 minutes after starting, before shutting down (but there is no minimum guaranteed idle period). New accesses within this time will be fast.
  • No state is saved between instances, and a new crypographic key is generated on each startup. This means that a CSRF error will occur if the front-end webpage is loaded from one instance and a form is submitted to a second instance.