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
47
48
49
50
# 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 once the user gives their account\
credentials, either for an existing account, or a new account.
This connection _may_ be rejected if the credentials are not valid.
### Server
When a client connects to the server, it sends the account credentials to\
authenticate (or an existing cookie on the client side).\
These are then sent to the API, which will create a session\
(or verify the previous one) 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`