Skip to content

samoilovartem/seat-split

Repository files navigation

Season Tickets Tech Backend

Description:

Current repository is a backend part of comprehensive STT project, which is a working name for Seat Split consignment portal. Seat Split allows ticket season holders to sell their tickets to other fans. Currently, we support only sports events, but in the future we are planning to expand our business to other events like concerts, theaters, etc.

Main stack:

  • Python
  • Django
  • Django Rest Framework
  • PostgreSQL
  • Redis
  • Celery
  • Docker
  • Poetry

Installation:

  1. Clone the repository from GitHub.
  2. Create .env in django-backend directory using .env.example.
  3. Install Docker and launch the daemon.
  4. Cd to project's root and run docker compose up --build.

Project structure:

Directories:

  • django-backend - contains all necessary files for Django backend.
    • apps - contains all existing django applications and common (among them) files.
    • config - contains standard Django settings files.
    • templates - contains Django admin template settings as well as email templates.
  • nginx - contains all necessary files for nginx configuration (in case we are the one who manage nginx).
  • shell_scripts - contains all shell commands that can make our life much easier.
    • create_requirements.sh - creates dev-requirements.txt and prod-requirements.txt files.
    • docker_deploy.sh - builds docker container and pushes it to Heroku.
    • run_tests.sh - runs all tests and creates html report.
    • make_project_structure_tree.sh - creates project structure.
    • heroku_backup.sh - contains all necessary commands to backup Heroku database.
    • count_lines_of_code.sh - counts all lines of code in the project.

Separated files:

  • .dockerignore - list of files or directories that are excluded from getting into docker container.
  • ruff.toml - just an extension of main ruff linter settings stored in pyproject.toml.
  • .gitignore - list of files or directories that are excluded from getting into git repository.
  • .pre-commit-config.yaml - custom settings for ruff and isort linters hooks.
  • docker-compose.yml - file-constructor, that allows to build docker containers. Used for local development only.
  • Dockerfile - file-instruction of how to build docker image for services like Heroku and Railway.
  • Dockerfile-dev - file-instruction of how to build docker image for local development. This is the file, that docker-compose.yml is using for building docker container to run it locally.
  • Dockerfile-prod - file-instruction of how to build docker image for production deployment in case we use VPS.
  • pyproject.toml - custom project's settings. This file contains all necessary information about the project itself, dev and prod dependencies.

Important environment variables:

First of all, check out .env.example file. It contains all necessary environment variables that are used in the project. Here is the detailed explanation of some of them (the rest are self-explanatory):

  • ROLLBAR_ACCESS_TOKEN - token for Rollbar service, which is used for error tracking.
  • CELERY_AGGREGATED_SLACK_NOTIFICATION_COUNTDOWN - countdown for Celery task, which aggregates all ticket created notifications and sends them to Slack.
  • STT_NOTIFICATIONS_BOT_API_TOKEN - token for Slack bot, which is used for sending notifications to Slack.
  • STT_NOTIFICATIONS_CHANNEL_ID and STT_WEEKLY_ISSUES_REPORT_CHANNEL_ID - ids of Slack channels, where notifications and weekly reports are sent. For test purposes we are using #test-channel channel with id C06BH3YAPV4.
  • HEALTH_CHECK_TOKEN - token for health check endpoint. Used for monitoring purposes. Basically you are the one who generates it and inputs as an environment variable. Then you use it while sending requests to health check endpoint.
  • BUSINESS_TOTAL_EXPENSES - percentage of total expenses that are used for business purposes. For example, if we list clint's ticket for $100 and our percentage is 20% (insert as 0.2), then client will get $80 and we will get $20.
  • GENERATE_EMAILS_TOKEN - token for /generate_random_data_with_provided_domain_or_state/ endpoint. Used for generating random emails with provided domain or state.
  • GITHUB_ACCESS_TOKEN - token for Weekly Issues Report. Used for getting all issues from Github and sending them to Slack.

Health check endpoint:

We have a health check endpoint, which is used for monitoring purposes. It is located at api//health-check/ and requires HEALTH_CHECK_TOKEN environment variable to be set. This is based on django-health-checkpackage, so all information about it can be found here. In order to call this endpoint, you need to provide Authorization header with a value, which is equal to HEALTH_CHECK_TOKEN environment variable:

"Authorization": "HEALTH_CHECK_TOKEN"

Example of the successful response:

system_status_check.png

Currently it checks the following services:

  • Database (PostgreSQL)
  • Cache (Redis)
  • Celery

Database structure:

We are using PostgreSQL as our main database. The database structure is quite simple and can be found either by this link or you can create a new diagram at dbdiagram.io by copying the code from this file. It contains all necessary information about tables, their fields and relations between them.

Deployment to Heroku

Using Container Registry:

  1. Prepare correct Dockerfile
  2. Use this command to build the container:
    docker build -t registry.heroku.com/<app_name>/web .
  3. Push the container to registry.heroku.com:
    docker push registry.heroku.com/<app_name>/web
  4. Release the container to production:
    heroku container:release -a <app_name> web

Also, you can simply run docker_deploy.shand script will complete these 3 commands for you.

Deployment to Railway

Using Github Actions:

Railway will automatically deploy the app in case main branch has been updated.

Git workflow:

We are using simple Git workflow with main and develop branches. All new features should be developed in separate branches (feature/<relevant_feature_name>) and then merged into develop branch after Pull Request is reviewed and approved. The next step would be creating a Pull Request from develop to main branch and merge it.

PR template:

  1. What does this PR do?
  2. Why are we doing this?
  3. How should this be manually tested?
  4. Any background context you want to provide?
  5. What are the relevant tickets?
  6. Screenshots (if appropriate).
  7. Questions.

Getting events data:

A full instruction on how to get required data using SkyBox personal account and Postman can be found here.

Useful notes:

  1. Heroku python manage.py collectstatic issue solution can be found here.
  2. Django-tabulator-example is here.
  3. Responsive tables using Django and htmx. The main article is here. Github source code.
  4. Django-tables2 documentation.
  5. Django-filter documentation.
  6. Django-crispy-forms documentation.
  7. Django Model meta options.
  8. Detailed Django Form explanation.
  9. Django Widget Tweaks is here.
  10. Django permissions detailed article.
  11. If you ever you deleted Django migrations
  12. Git Cheat Sheet
  13. JWT decoding
  14. Using dictionary as filter value
  15. Super useful approaches of how to get user and group permissions is here

Useful commands:

  1. Access project's bash:
    heroku run bash -a <heroku app name>
  2. Check all releases:
    heroku releases
  3. Check all info about particular release:
    heroku releases:info <release version number>
  4. If ever we deployed buggy code or something goes wrong with current release:
    git revertand redeploy it again.
  5. If we have some problems with heroku platform, then better to use:
    heroku rollback <release version number (optional)>
  6. Heroku app logs:
    heroku logs -n 1500or heroku logs -tto maintain them live
  7. Safely delete all rows from database:
    python manage.py truncate --apps <app_name> --models <model_name>
  8. Reset PK in postgresql DB (apply only after deleting all info from the table):
    python manage.py sqlsequencereset <app_name> | python manage.py dbshell
  9. Safely delete an app:
    python manage.py migrate <app_name> zero
    After running this command we can delete an app from INSTALLED_APPS and delete a corresponding directory
  10. Check project's files with flake8 and black before making commit:
    pre-commit run --all-files

About

No description, website, or topics provided.

Resources

Contributing

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published