Uruchamianie

Z użyciem Dockera

Budowanie:

docker build -t wmiadventure_backend .

Jeżeli chcemy podłączyć się do serwera bazodanowego hostowanego poza naszą maszyną możemy przekazać dodatkowe argumenty (za pomocą składni: --build-arg ZMIENNA=WARTOSC):

DB_ADDRESS=adres - Adres bazy danych PostgreSQL (Inne bazy nie są wspierane)
DB_PORT - Port bazy danych - domyślnie ustawiony na 5432.
DB_USER - nazwa użytkownika bazy
DB_NAME - nazwa bazy
DB_PASSWD - hasło do bazy
DJANGO_SECRET - Klucz SECRET_KEY używany do kryptografii w Django
DJANGO_DEBUG=(True|False) - Tryb DEBUG w Django

Uruchamianie:

docker run wmiadventure_backend

Uruchomi serwer na localhost:8000

Bez Dockera

Wymagania:

python: >= 3.9

Instalujemy zależności do Pythona:

cd WMIAdventure/backend
pip install -r requirements.txt

Inicjalizujemy bazę danych i uruchamiamy serwer:

cd WMIAdventure_backend
python manage.py migrate
python manage.py runserver 0.0.0.0:8000

Uruchomi server na localhost:8000.

Jeżeli chcemy skorzystać z zewnętrznej bazy danych, to musimy ustawić zmienne środowiskowe (Lista kluczy opisana wyżej w instrukcji dla Dockera:

Linux:

export KLUCZ=WARTOŚĆ

Windows/Powershell

Set-Variable -Name "KLUCZ" -Value "WARTOSC"

Techonolgie

Do tworzenia systemu backendowego wykorzystujemy język Python3 z techologiami Django i django-rest-framework. Całość opakowana jest w kontener Dockera. Więcej informacji o zależnościach znajdziemy w pliku requirements.txt

Dokumentacja

Aktualną dokumentację programistyczną do backendu znajdziemy w folderze docs. Planujemy również stworzenie dynamicznej dokumentacji opartej o Sphinx hostowaną razem z całą aplikacją.

Struktura

Kod znajduje się w folderze WMIAdventure_backend. Wszystkie katalogi i pliki zgodne są z konwencją narzuconą przez Django, "appki" to poszczególne moduły systemu.

Logika Biznesowa poza-djangowa

Przy implementowaniu czystej logiki biznesowej wychodzącej poza MVC nie korzystamy z Django. Pliki umieszczamy w appce odpowiedzialnej za realizację tej logiki w osobnym folderze businesslogic. Podążamy tam schematami znanymi z obiektowego podejścia programistycznego - podobnie jak w Javie - jeden plik zawiera jedną klasę; testy do klas analogicznie.

Dokumentacja - folder docs

Wszystkie diagramy, dokumenty programistyczne przechowujemy w tym folderze, podzielone ze względu na kategorię (np diagramy sekwencji w sequence_diagrams).

Moduły

TODO: Każdy z tych modułów powinien mieć odnośnik do dokumentacji ze Sphinxa w przyszłości.

IngameUsers

Nazwa tego modułu jest trochę niefortunna, miała na celu jasno odróżnić ten moduł od modułu Users, powinna nazywać się po prostu Profiles (Django w dużej mierze bazuje na nazwie, wymaga dużo zmian). Każdy użytkownik na profil i wiele danych, które go dotyczą. Wszystkie te informacje powinny znaleźć się w tej appce.

Battle

Moduł odpowiedzialny za realizacje pojedynków między graczami. Poza samymi modelami i widokami jest tutaj dużo logiki biznesowej która opisuje przebieg pojedynków i tłumaczy klasy modelowe na klasy business logic, żeby wykonywać na nich operacje. Znajdują się tu efekty kart, pętla walki, kolejka ruchów, buffy.

Testowanie

Do testów powstała klasa Creator, która tworzy wiele obiektów potrzebnych do testów. Przed wykonaniem klasy testowej powinniśmy stworzyć kreator (w metodzie setUpClass żeby był dostepny dla całej klasy i usunąć go w tearDownClass wykonując metodę perform_deletion. Jeżeli tego nie zrobimy, testy nie wyjdą przez błędy w Creatorze.

Cards

Appka przechowująca modele kart.

Users

proposed_content

Moduł odpowiedzialny za obsługę proponowanych treści tworzonych w edytorach.