1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
# Deck Builder (code-named 'laurelin')
See `dev` branch for latest changes.
---
A multiplayer deck building game.
## Shortest possible explanation of the structure
```
Client <-> Server <-> API <-> Persistent database (PSQL)
API <-> Session store (Redis)
```
The client only communicates with the server.\
The server is authorative, and has the final say in _ALL_ things.\
The server communicates with a web API that handles all database\
functionality.\
The API is *not* exposed publicly (thus, it will not require authentication\
or authorization for most endpoints), and all request go through the server.
### Client
The client creates a connection to the server on startup.
### Server
When a client connects to the server, it can't do much at the start,\
because the user has to send account credentials to authenticate.\
These are then sent to the API, which will create a session and return\
a cookie. The cookie should then be passed to the client.
Should the cookies for both users in a game be stored on the server as well?
In-memory, but just so the user doesn't have to send it with every request,
to save on the traffic.
### API
The web API has access to a PSQL server and a Redis server.
### PSQL and Redis
PostgreSQL is used for storing/persisting data.
Redis is used for storing user sessions.
## Commit conventions
Commits after 09.01.2023 MUST follow [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/).
Things to remember:
* everything lowercase
* allowed scopes are `shared`, `client`, `server` and `api`