https://github.com/febus982/auth-study
https://github.com/febus982/auth-study
Last synced: 12 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/febus982/auth-study
- Owner: febus982
- Created: 2024-02-24T09:33:36.000Z (about 2 years ago)
- Default Branch: main
- Last Pushed: 2024-03-02T12:28:28.000Z (about 2 years ago)
- Last Synced: 2025-02-11T09:50:07.038Z (about 1 year ago)
- Language: Python
- Size: 143 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Bootstrap python service
[](https://github.com/febus982/bootstrap-python-fastapi/actions/workflows/ci-pipeline.yml)
[](https://github.com/febus982/bootstrap-python-fastapi/actions/workflows/python-tests.yml)
[](https://codeclimate.com/github/febus982/bootstrap-python-fastapi/test_coverage)
[](https://codeclimate.com/github/febus982/bootstrap-python-fastapi/maintainability)
[](https://mypy-lang.org/)
[](https://github.com/charliermarsh/ruff)
[](https://github.com/psf/black)
[](https://github.com/PyCQA/bandit)
This is an example implementation of a python application applying
concepts from [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)
and [SOLID principles](https://en.wikipedia.org/wiki/SOLID).
* The repository classes are isolated behind interfaces, enforcing the [Interface Segregation principle](https://en.wikipedia.org/wiki/Interface_segregation_principle)
and the [Inversion of Control](https://en.wikipedia.org/wiki/Inversion_of_control) design pattern
* The application frameworks are decoupled from the domain logic
* The storage layer is decoupled from the domain logic
This template provides out of the box some commonly used functionalities:
* API Documentation using [FastAPI](https://fastapi.tiangolo.com/)
* Async tasks execution using [Celery](https://docs.celeryq.dev/en/stable/index.html)
* Repository pattern for databases using [SQLAlchemy](https://www.sqlalchemy.org/) and [SQLAlchemy bind manager](https://febus982.github.io/sqlalchemy-bind-manager/stable/)
* Database migrations using [Alembic](https://alembic.sqlalchemy.org/en/latest/) (configured supporting both sync and async SQLAlchemy engines)
* [TODO] Producer and consumer to emit and consume events using [CloudEvents](https://cloudevents.io/) format on [Confluent Kafka](https://docs.confluent.io/kafka-clients/python/current/overview.html)
## Documentation
The detailed documentation is available:
* Online on [GitHub pages](https://febus982.github.io/bootstrap-python-fastapi/)
* Offline by running `make docs` after installing dependencies with `make dev-dependencies`
## How to use
Create your GitHub repository using this template (The big green `Use this template` button).
Optionally tweak name and authors in the `pyproject.toml` file, however the metadata
are not used when building the application, nor are referenced anywhere in the code.
Using Docker:
* `make containers`: Build containers
* `docker compose run --rm dev make migrate`: Run database migrations
* `docker compose up dev`: Run HTTP application with hot reload
* `docker compose up celery-worker`: Run the celery worker
* `docker compose run --rm test`: Run test suite
Locally:
* `make migrate`: Run database migrations
* `make install-dependencies`: Install requirements
* `make dev-dependencies`: Install dev requirements
* `make update-dependencies`: Updates requirements
* `make migrate`: Run database migrations
* `make dev`: Run HTTP application with hot reload
* `make test`: Run test suite
## Other commands for development
* `make check`: Run tests, code style and lint checks
* `make fix`: Run tests, code style and lint checks with automatic fixes (where possible)
## Multistage dockerfile configuration
Python docker image tend to become large after installing the application requirements
(the slim base is ~150 MB uncompressed), therefore it's important to spend efforts
to minimise the image size, even if it produces a slightly more complex multistage
Dockerfile.
The following setup makes sure the production image will keep to a minimal size ("only" 390MB):
* 150MB base image
* 165MB python installed dependencies
* 73MB poetry + updated pip
Using the following pipeline the "test" image is instead ~850MB, more than 400MB that would
end up as a cost in traffic on each image pull.
