Some people were searching my GitHub profile for project examples after reading the article on FastAPI best practices. Unfortunately, I didn't have useful public repositories, but only my old proof-of-concept projects.
Hence, I have decided to fix that and show how I start projects nowadays, after getting some real-world experience. This repo is kind of a template I use when starting up new FastAPI projects:
- some configs for production
- gunicorn with dynamic workers configuration (stolen from @tiangolo)
- Dockerfile optimized for small size and fast builds with a non-root user
- JSON logs
- sentry for deployed envs
- easy local development
- environment with configured postgres and redis
- script to lint code with
ruff
andruff format
- configured pytest with
async-asgi-testclient
,pytest-env
,pytest-asyncio
- SQLAlchemy with slightly configured
alembic
- async SQLAlchemy engine
- migrations set in easy to sort format (
YYYY-MM-DD_slug
)
- pre-installed JWT authorization
- short-lived access token
- long-lived refresh token which is stored in http-only cookies
- salted password storage with
bcrypt
- global pydantic model with
- explicit timezone setting during JSON export
- and some other extras like global exceptions, sqlalchemy keys naming convention, shortcut scripts for alembic, etc.
Current version of the template (with SQLAlchemy >2.0 & Pydantic >2.0) wasn't battle tested on production, so there might be some workarounds instead of neat solutions, but overall idea of the project structure is still the same.
cp .env.example .env
docker network create ffmemes_network
docker-compose up -d --build
Format the code with ruff --fix
and ruff format
docker compose exec app format
- Create an automatic migration from changes in
src/database.py
docker compose exec app makemigrations *migration_name*
- Run migrations
docker compose exec app migrate
- Downgrade migrations
docker compose exec app downgrade -1 # or -2 or base or hash of the migration
All tests are integrational and require DB connection.
One of the choices I've made is to use default database (postgres
), separated from app's app
database.
- Using default database makes it easier to run tests in CI/CD environments, since there is no need to setup additional databases
- Tests are run with upgrading & downgrading alembic migrations. It's not perfect, but works fine.
Run tests
docker compose exec app pytest
The template is using Just.
It's a Makefile alternative written in Rust with a nice syntax.
You can find all the shortcuts in justfile
or run the following command to list them all:
just --list
Info about installation can be found here.
We are using pg_dump
and pg_restore
to backup and restore the database.
- Backup
just backup
# output example
Backup process started.
Backup has been created and saved to /backups/backup-year-month-date-HHMMSS.dump.gz
- Copy the backup file or a directory with all backups to your local machine
just mount-docker-backup # get all backups
just mount-docker-backup backup-year-month-date-HHMMSS.dump.gz # get a specific backup
- Restore
just restore backup-year-month-date-HHMMSS.dump.gz
# output example
Dropping the database...
Creating a new database...
Applying the backup to the new database...
Backup applied successfully.