# 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`