Headless Django Server Application
A starter project for a headless REST/GraphQL API powered by Django
Technologies
Local Development
Requirements
- Editor of choice (VSCode, Pycharm)
- Docker for Desktop (With appropriate licence)
VSCode
- Clone project
- Open project in VSCode, you should be prompted to install the recommened VSCode extensions automatically
- You will be prompted that this project is setup for "Dev Containers"
- Click Open Dev Container from the prompt
- After a short while, you will have a terminal and the full project running locally
- You will have to apply migations to your database, run
migrate
in the terminal - run
start
in your terminal to start the backend service or use the editor built in run configuration for debugging - Navigate to
http://127.0.0.1:8000/api/schema/redoc/
orhttp://127.0.0.1:8000/api/schema/swagger-ui/
to view API docs
Unix/Linux/Windows - Any Code Editor
make start
Starts the full project and related services in docker- In a new terminal/side by side,
make shell
will give you a shell dev environment for running commands against the running application - Inside the shell created by
make shell
, runmigrate
to ensure your database is up to date.
Troubleshooting
- WARNING:
You have X unapplied migration(s).
- Run
migrate
in the development shell
Workflow Guides
While in the local development shell (run make shell
)
- Adding New Dependencies
add DEPNAME
add --help
- alias for
poetry add
*
- Generating Migration Files
poetry run python manage.py makemigrations
- Applying Migrations
migrate
- alias for
poetry run python manage.py migrate
Testing
Philosophy
Write tests. Not too many. Mostly integration. https://kentcdodds.com/blog/write-tests
Use the GIVEN-WHEN-THEN
style of representing tests in order to
encourage behavior-driven development.
TDD/BDD can be used but specific python toolings for gherkin/cucumber have been omitted for you to add if needed.
Testing Structure
- Tests are added in the
/tests/*
root folder - Add your test to the specific app folder and organize them by
integration/
orunit/
Factories
FactoryBoy is used to simplify testing.
Writing a Test
Naming
Test cases should follow the following pattern:
test_[given]__[when]__[then]
Examples:
test_product_has_been_purchased__delete_product__rejected
Structure
Just like good code, good tests should be self-documenting. Tests should have easy-to-read sections of setup (GIVEN), action (WHEN), expected result (THEN)
# GIVEN
...
# WHEN
...
# THEN
...
Running Tests
poetry run pytest
Running Tests in Parallel
poetry run pytest -n auto
Future Considerations
- update
settings.py
file structure forcommon_settings.py
,testing_settings.py
, so on - Rework dockerfile to be multi-stage dev/prod
- Add Redis to dev image/update django cache backend
- add pre-commit linting for commit messages
- use
bumpversion
for version managment if desired - add specific CI config for running tests